|
From: Chris F. <cd...@fo...> - 2011-12-06 21:49:23
|
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? 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? - Chris |