On Do, 2011-01-27 at 21:11 +0000, Patrick Ohly wrote:
> Hello!
> 
> I updated the libsynthesis used by SyncEvolution from something about
> half a year old (can dig out the details) to Lukas' latest branch.
> 
> The nightly testing shows that copying photos to and from peers in vCard
> 2.1 fails. vCard 3.0 with Synthesis server seems okay (but I haven't
> verified whether they really get transmitted).

That was a red herring. I now think that it also fails with vCard 3.0.

> I compared against SyncEvolution 1.1.1 and I see differences in the
> logs. From 1.1.1:
> 
> Parsing:
> PHOTO;TYPE=PNG;ENCODING=b:iVBORw0KGgoAAAANSUhEUgAAACQAAAAXCAYAAABj7u2bAAAAB
>  mJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1gEICjgdiWkBOQA
>  ...
>  xQfsIfbqGIlf17k6Bb/Ae0cnahfg6KuAAAAAElFTkSuQmCC
> 
> Field list:
> - 71 :       blob PHOTO           [   0,   0,   516] : �PNG
> 
> 
> Generated:
> PHOTO;ENCODING=BASE64:iVBORw0KGgoAAAANSUh...nahfg6KuAAAAAElFTkSuQmCC
> 
> 
> From current code:
> 
> [same input data]
> - 71 :       blob PHOTO           [   0,   0,   688] : 
> iVBORw0KGgoAAAANSUh...0cnahfg6KuAAAAAElFTkSuQmCC
> PHOTO;ENCODING=BASE64:aVZCT1J3MEtHZ29BQUFB...
> 
> Note that the older libsynthesis seems to print the field list
> differently. I don't know where the 516 != 688 difference comes from,
> the content seems to be parsed fine.

The difference is that the older lib decoded base64 encoding and stored
the decoded data in the field. The new lib doesn't, and then the encoder
applies base64 encoding again to the already encoded data.

This changed in the very latest commit:

TMimeDirProfileHandler::parseProperty():

3529d3cb (Lukas Zeller   2011-01-25 14:45:16 +0100 3906)         if 
(encoding==enc_quoted_printable)
3529d3cb (Lukas Zeller   2011-01-25 14:45:16 +0100 3907)           
storeUnprocessed = false; // QP will be decoded, so param must not be stored
3529d3cb (Lukas Zeller   2011-01-25 14:45:16 +0100 3908)         else
3529d3cb (Lukas Zeller   2011-01-25 14:45:16 +0100 3909)           encoding = 
enc_none; // other encodings will not be processed

commit 3529d3cb0929aed94b2568c0e74f3ec746b7be7a
Author: Lukas Zeller <l...@plan44.ch>
Date:   Tue Jan 25 14:45:16 2011 +0100

    engine: implemented "unprocessed" wildcard properties to allow handling 
unknown extensions (like X-xxxx properies

Lukas, should that code above perhaps be conditional on "current
property is 'unprocessed' wildcard"? Right now it applies to all
properties, including PHOTO, and thus skips the decoding in
decodeValue().


-- 
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
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to