> > 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) >
Can we replace sync_vtype_convert altogether? I think we need a standard vcard parser that can be accesed by all plugins, but one that also handles unkown vcard fields in a sensible way. I find that if one plugin ignores a cvard entry because it does not recognise it, then the multisync engine thinks the plugin device has device deleted that entry and promptly deletes the same entry from the other plugin device. Is this a known bug? I would like to see a method by which plugins can register the vcard fields they handle with the sync engine. Thus the sync engine only passes those fields to the plugin, and properly avoids deleting fields that only one plugin handles. Since its too late to change the plugin architecture, we may be able to get something similar using a cleverer sync_vtype style function. -- Stewart Heitmann ------------------------------------------------------- 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 Multisync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/multisync-devel
