On Fr, 2011-07-22 at 14:39 +0200, Lukas Zeller wrote: > 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 <[email protected]> > 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.
I couldn't think of cases where avoiding binary encoding might have a negative effect, but you are right, it is not according to spec and it makes sense to not change existing behavior. I'll add your patch and continue with integration of the bmc19661 branches into a SyncEvolution release, unless you have further comments on the other commits. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
