Re: [SyncEvolution] uri + binary PHOTO values (was: Re: [os-libsynthesis] field merging + parameters)

On Jul 21, 2011, at 14:13 , Patrick Ohly wrote: > On Do, 2011-07-21 at 12:21 +0200, Patrick Ohly wrote: >> Now there is only one other problem with PHOTO uris. They get encoded as >> binary data: >> >> PHOTO;VALUE=uri:http://example.com/photo.jpg >> => >> PHOTO;ENCODING=B;VALUE=uri:aHR0cDovL2V4YW1wbGUuY29tL3Bob3RvLmpwZw== >> >> Is that because PHOTO is defined as "blob"? >> >> Would it make sense to be selective in the encoder for "blob" and only >> use binary encoding if the content contains non-printable characters? > > This patch has the desired effect: > > [...] > > I tried it with both binary PHOTO and VALUE=uri. Looks fine, however I'd prefer to restrict that functionality to a new convmode CONVMODE_BLOB_AUTO, instead of changing the behaviour of CONVMODE_BLOB_B64 which has the B64 encoding as a promise in its name :-). I added this in the following patch (which fits on top of current meego/bmc19661). From 1161e5f15100432f7edad792bc72fe64ca22bf00 Mon Sep 17 00:00:00 2001 From: Lukas Zeller <luz(a)plan44.ch&gt; Date: Fri, 22 Jul 2011 14:34:24 +0200 Subject: [PATCH] "blob" fields: Added separate CONVMODE_BLOB_AUTO conversion mode for fields that should be rendered as B64 only in case they are really non-printable or non-ASCII This is an addition to 8d5cce896d ("blob" fields: avoid binary encoding if possible) to avoid change of behaviour for CONVMODE_BLOB_B64.