Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[deloptes <del...@ya...>]

Chris Frey wrote:

> 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".

As I understood there are about 48 functions exposed, so it won't be that
kind of a "giant".

> 
> 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.

This is actually what libsyncml is doing and the current plugin is using the
database from opensync. And the synthesis engine has it's own database -
correct, or by DB you mean the DB on the device (i.e. the mobile phone)?
Perhaps the plugin can use the DB with the API, so the logic may change
here - we need to have a look what is needed and what is possible.

> 
> 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.

I think here is the question how and if it is possible to be done. Even if
we use a DB, we do not need to support everything in the same time and in
the same group, but just the subset that is common for the peers (i.e.
akonadi and the mobile)

When we discover/configure our opensync group members we already know what
they support. (I usually double check the device config when initializing
as I change setup on the way and forget to change back)
So can we get this information when using libsynthesis (I suppose yes)? 
It is done actually by libsyncml at the moment and is working pretty well.

Next step: opensync initializes and it will know what capabilities are
provided by the peers in the opensync group (i.e. akonadi and mobile).
We must provide those capabilities to the synthesis engine as DevInf and ask
for a sync. We will receive exactly the data that both peers support (and
this is what libsyncml is doing ATM), so when both engines know what they
support before starting the sync, I don't see any problem to let them sync
it.

About the "correct order" of "doing things" in SyncML - this is exactly the
reason why we want to use it and I think nothing will be wrong with it.
Can you explain what you mean by "correct order" and "full controll of the
sync"?. What does it mean?

I would like to keep all of it as simple as possible, as simple things are
great :-)

thanks for the discussion, I really appreciate

regards