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

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

Chris Frey wrote:

> On Fri, Dec 02, 2011 at 01:18:27AM +0100, deloptes wrote:
>> I think it fits better then we suspect, if I understood correctly what I
>> read.
>> 1) In OpenSync's plugin you have the main sync and the data sync(s). The
>> main sync will represent the UI API and the latter the datastore API. The
>> calls can be handled either by the opensync plugin or passed to the
>> engine and vice versa (depends what we want to achieve). This means
>> A)the opensync plugin will drive the engine in the main sync and provide
>> the transport etc.
>> B) The data syncs will cover the data store work (and will act as DB
>> plugins to the synthesis and object types to the opensync engine - i.e.
>> contacts, events and so on).
>> 2) Respective DevInf will be used/generated after or during both sides
>> are getting discovered/configured.
>> 3) If it is necessary for the synthesis engine to lead the sync, we can
>> do this against the opensync database as Chris suggested, and we will
>> mark the entries to know in which state they are (there is a mechanism in
>> opensync to do so).
> 
> Hi deloptes,
> 
> It almost sounds like you're planning to make one plugin that connects to
> both opensync and libsynthesis at the same time.  Is that correct?

Yes, it will be an opensync plugin and i) will drive libsynthesis (thus
follow the client/server UI logic) from the mainSink and ii) will provide
DB plugins to the synthesis engine from the DataSink.

I will have some opensync and synthesis related question on this, though the
documentation in the synthesis project looks much better to me.

If this does not work we'll probably need to write something like osynctool
that will drive the synthesis engine from user perspective and interact
with opensync accordingly - it's like plan B solution ;-)

What I would like is to avoid unnecessary work as far as possible.

> 
> That would be cool if you can swing it. :-)
> 
> I don't think I'd worry about getting the classes correct just yet.
> I'd try writing just a skeleton framework, with maybe printf() statements
> following the logic, just as a simple proof of concept.  Once we have
> such a framework, I can certainly look at it, and provide suggestions
> on a class hierarchy.
> 
> Would that help?
> 

Yes, this would be great. Unfortunately, I'm preoccupied with private and
business stuff until around Christmass and I'm working occasionally on it
mainly reading docs and drawing drafts from time to time. I prepared a
Find...cmake file for libsynthesis and tried to compile empty classes to
check if linking works and so. Lately I did research on the logic behind
synthesis, so that I may think it could be theoretically doable - one way
or another (plan B). However any effort with success will bring us to
another level of opensync and make it usable at least for me.

I have additional question. Though it might be very profitable to implement
obex transport in terms of mobile phones, it might be more helpful for
testing to implement http client/server. What do you think?

So in sum the task of the project would be to make a prototype with empty
calls that would use synthesis syncml over http server/client transport.
It should be possible to configure them in pair for testing - correct?

What about the licensing question - did you have a look into the
libsynthesis licenses?

regards