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