On Tue, 2009-08-04 at 16:20 +0100, Bob Eggers wrote: > Hi Patrick, > > We're still in design phase at this point, trying to get all the ducks > in a row. It's likely we'll implement the EvolutionSyncSource class. > It's possible there is a private, backdoor interface to access > revision/modtime, which would be ideal. My modtime hack is the last > line of defense; I always like to have one of those. We'll begin > implementation shortly, and we're aiming for as few > unknowns/dependencies as possible in that phase.
"unknowns/dependencies" as in "unimplemented features in SyncEvolution"? Makes sense. Would it be acceptable for you to use the development branch? I'd like to get at least some API changes/cleanups implemented before people seriously write new code against the current API. This API change is unlikely to break the code at runtime, it's more of the "let's break all source code and put the pieces back together" variety. Besides, the master trunk will be tested again against all servers once 0.9 is out. Can you explain a bit more about what you are trying to achieve? That would help to understand what you need and how it could interact with the rest of SyncEvolution. For example, how do you intend to provide a GUI? Have you seen the D-Bus-based design article [1] and the discussion here on the list about the syncevo-dbus-server<->GUI API? The push listener would fit into such an architecture well. [1] http://moblin.org/documentation/syncevolution/direct-synchronization-aka-syncml-server -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
