|
From: Chris F. <cd...@fo...> - 2011-11-01 21:00:46
|
On Tue, Nov 01, 2011 at 09:14:40PM +0100, Patrick Ohly wrote: > CtCap answers that question. As Lukas said, the Synthesis engine uses > that information to avoid data loss. That won't work when invoked as > part of OpenSync. Nor can OpenSync do that job because a generic SyncML > plugin based on libsynthesis can't report the necessary information back > to the OpenSync engine. Thanks for your explanations. Hopefully I understand this now. :-) Assumption: the "giant wrapper" opensync plugin will sync all SyncML devices at once. It would show up in the OpenSync group list as "bunch of syncml devices". So, in the case of us writing a "giant wrapper", one part of that would be a DB plugin to Synthesis that simulates an actual SyncML device, but writes the data to an sqlite database or something. This fake device would have its own capabilities list in the form of DevInf. So, this "device" would support _everything_, including for example BDAY, but other devices in the Synthesis SyncML group might not. Libsynthesis would make sure that the BDAY in our database would not get deleted. (I'm assuming this is true, otherwise, none of this works.) And if there was at least one other device that supported BDAY, this could update our copy as well. The giant wrapper OpenSync plugin would run a Synthesis sync first, at the beginning of the OpenSync sync; then create its own list of changes for OpenSync, based on its database; update its database with incoming OpenSync changes; and just before finishing, would run another Synthesis sync. In this case, Libsynthesis would make sure that other SyncML devices would not overwrite our BDAY, and the OpenSync capabilities list would make sure the same didn't happen on the opensync side. In the common case, there would just be one device in the Libsynthesis group and one app in the OpenSync group, and as long as the fake device's database supported every possible piece of data, nothing would be lost. What am I missing? :-) - Chris |