On Tue, 2005-01-04 at 03:41, Stewart Heitmann wrote: > > > 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.
ups, then i understood you wrong in the beginning. i thought you meant entry as a whole object (like a vcard) and not as a single field. It is true of course that multisync discards fields that are not understood by both sides. It does this because the granularity of the data it can sync is at a object level (vcards for example) and not at a field level. I see 2 approaches to solve this: - Use device capabilities to tell the syncengine which fields one device does support and use this information to merge the data. This approach can be complicated and afaik one of the members of the OMA has a patent on this approach. - Use a archive. A archive is a sync source which is accessible only by the syncengine and it must support a format which can store all fields from all members. When a member synchronize, he always gets merged with the archive. This way the archive contains all informations and never looses it just because a member cannot support a field. > > 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. ------------------------------------------------------- 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
