On Thu, 2004-12-16 at 13:16 +0200, Mika Raento wrote: > Hi > > Moving on to syncing contacts from evo to my 7650, I've noticed a > problem with the sync_vtype_convert() handling of data. An evo mailing > list looks like: > > > BEGIN:VCARD > VERSION:3.0 > X-EVOLUTION-FILE-AS:CONTEXT-tktl > FN:CONTEXT-tktl > N:;CONTEXT > X-EVOLUTION-LIST:TRUE > X-EVOLUTION-LIST-SHOW_ADDRESSES:TRUE > UID:pas-id-406BDA250000005A > EMAIL;X-EVOLUTION-DEST-CONTACT-UID="pas-id-3DC642D000000003";X-EVOLUTION-DE > ST-NAME="name";X-EVOLUTION-DEST-EMAIL="email-conti > nued ";X-EVOLUTION-DEST-HTML-MAIL=FALSE:name <email-conti > nued > > EMAIL;X-EVOLUTION-DEST-CONTACT-UID="pas-id-3DC777A400000004";X-EVOLUTION-DE > ST-NAME="name";X-EVOLUTION-DEST-EMAIL="email-conti > nued";X-EVOLUTION-DEST-HTML-MAIL=FALSE:name <email-conti > nued> > EMAIL;X-EVOLUTION-DEST-CONTACT-UID="pas-id-3FD57FAC00000002";X-EVOLUTION-DE > ST-NAME="name";X-EVOLUTION-DEST-EMAIL="email";X-E > VOLUTION-DEST-HTML-MAIL=FALSE:name <email> > END:VCARD > > Now this breaks several assumptions in sync_vtype_convert(): that the > head part of a field (before ':') is max 255 characters and that the ':' > is contained on the first line of a field. The result after the > conversion is: > > VERSION:3.0 > X-EVOLUTION-FILE-AS:CONTEXT-tktl > FN:CONTEXT-tktl > N:;CONTEXT > X-EVOLUTION-LIST:TRUE > X-EVOLUTION-LIST-SHOW_ADDRESSES:TRUE > UID:pas-id-406BDA250000005A > nued ";X-EVOLUTION-DEST-HTML-MAIL=FALSE:name <email > > ued";X-EVOLUTION-DEST-HTML-MAIL=FALSE:name <email> > VOLUTION-DEST-HTML-MAIL=FALSE:name <email> > END:VCARD > > which, as you might guess, doesn't work very well. > > Now IMHO the sync_vtype_convert should be rewritten so that it parses > the string into a proper tree structure with no limits on where stuff > occurs. Now the handling of all the necessary conversions should be > easier to write and more modular as well. > > My question then is: what is happening in the 0.90 branch? Is this > already being done? Might we use libical for this? (I know there are > some issues with the library, but maybe just for parsing the stuff). > If this is not already being tackled/rewritten in 0.90 I could spend > some time on it.
Well i see several options how to handle this in 0.9: - use the current approach and fix the errors - use another library (i have never used libical though) - use the vcard stuff from evolution 2. They have their own vcard parsers now. download the evolutio-data-server source and in ./addressbook/libebook/e-vcard.h ./addressbook/libebook/e-vcard.c you have the parser (these sources can be used standalone) > > Mika Raento > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Multisync-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-devel
