> > 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? > > not that i know of. if it behaves this way, it is completely wrong of > course.
Well it does happen. If you think about it, then it must be so. If a user deletes a Vcard field from one device then the sync engine will correctly delete it from the other device. If instead, a plugin fails to handle the field (and discards it) then, as far as the sync engine is concerned, it is equivalent to the user deleting it. You can verify this yourself by syncing the kdepim and evolution plugins. KDE adressbook allows custom user vcard fields to be added, they take the form "X-KADDRESSBOOK-myfield:this is my custom field data" Any change to the vcard at the Evolution end promply causes the sync engine to delete the custom field from the KDE addressbook. I dont believe its a bug in either plugin. I believe it is a flaw in the multisync design because the sync engine currently has no way to diferentiate between fields deliberately deleted by the user and those silently ignored by the plugin. Thus I suggest it would ultimately be better if the sync engine only sent those particular vcard fields to a plugin that it knows the plugin can handle. However this requires each plugin to register the fields they handle with the sync engine on startup. Its a substantial design change so I dont imagine it would go into the 0.8x branch. Perhaps something to consider for 0.90 instead. Perhaps another solutions that is not so drastic: Imagine a function similar to sync_vtype_convert that could be called by the plugin to extract only those fields it wanted from the vcard data sent by the sync engine. A converse function could take merge specific fields back into the vcard data before returning it to the synce engine. It needs a decent vcard parser though. > I think this approach is not so good. A better solution would be a > "archive" based one, where the engine always syncs against a source > called the archive, which is only accessible by the syncengine and > contains can handle all available fields. When the syncengine syncs, it > always merges with the archive, this way no information is lost. This is > a planned feature for multisync-0.90 (but not in the very beginning) That wont fix the problem. It doesnt matter if you sync each device to a central archive or sync individual in pairs, as is currently the case. The problem rests with the sync engine presuming fields missing from the returned data are deliberately deleted fields. Currently, to work around the problem in 08x branch, the plugins must store (and return) all fields they receive from the sync engine whether they understand them or not. If the device simply hasnt got the capacity to store the extra fields (think PHOTO) then it is in trouble. -- Stewart Heitmann <[EMAIL PROTECTED]> ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Multisync-devel mailing list Multisync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/multisync-devel
