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

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

Lukas, thank you for your input, it is really great, that you posted this
information.
I just had an overview of the documentation and the sample code and had a
look into SyncEvolution. I recall a discussion with Patrick and his
analysis where he said it's virtually impossible because of opensync's
architecture, so I want to find out if it is feasible at the end and some
time and work is worth to put into this. I'll ask more questions in the
future, but what I need as a starting point is a kind of overview of
possible design.  I'll need some time to read in the docs, but the benefit
is clear, so I really appreciate this discussion. 

Lukas Zeller wrote:

> 
>> If I wanted to just talk to a SyncML device, get latest changes, get all
>> changes, delete records, add/modify changes, and then disconnect, would
>> that be possible with libsynthesis?
> 
> Unlike many of today's web APIs, a SyncML session has an awful lot of
> state - you can't use it to just ask for something in a REST-like manner.
> 
> The order of how you have to do the read and write operations is very
> strict in SyncML. Much in libsynthesis is about getting this order right,
> including numerous workarounds for peers that do it wrong. So libsynthesis
> has to be in control of the sync session from start to end.
> 
> On the DB backend API side, it calls out to plugins to get list of
> changes, read items, insert/update/delete items.
> 
> On the application API side, you can edit the client settings (URL,
> syncmode etc. - much what you see in a phone SyncML client, or my iOS
> apps), then initialize a session, and then "step" through the session.
> This means, it's not a single syncNow() function that blocks everything
> for a long time, but you have your own main loop which repeatedly calls
> the SessionStep() API function until the sync is done. SessionStep() has
> different return values, and informs you when a SyncML message is ready to
> be delivered to the peer, or when a SyncML response is expected from the
> peer. So the implementation of transporting messages (via HTTP, BT,
> whatever) is not in libsynthesis, but must (can!) be done in the calling
> code.
> 

>From my point of view this is doable, also the current libsyncml is doing
most of the same. I think if no one wants to maintain this library
libsynthesis can safely replace it. Perhaps there would be some more work
on the transport stuff, which I saw in SyncEvolution, but didn't have time
to study.

Chris, guys what is your opinion? Can we arrange a kickoff meeting in some
irc or skype or so?

regards