1:20 a.m.
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.
Cheers,
Bob
________________________________________
From: Patrick Ohly [patrick.ohly(a)intel.com]
Sent: Tuesday, August 04, 2009 3:49 AM
To: Bob Eggers
Cc: syncevolution(a)syncevolution.org
Subject: RE: SyncEvolution
Hi!
I kept thinking some more about this problem, additional comments
below...
On Mon, 2009-08-03 at 16:42 +0100, Patrick Ohly wrote:
On Mon, 2009-08-03 at 06:32 -0700, Bob Eggers wrote:
> 4) Our contacts records do not have a last mod time
Then it might be more suitable for implementing the EvolutionSyncSource
base class. In that class you initialize your data store, then report
added, updated, deleted items yourself.
The Evolution backends used to work like that based on a similar "change
list" kept by the Evolution Data Server. I found that a bit limited, for
example, reading that list was destructive (it wasn't possible to just
read the list without erasing it). It might be better with your
implementation.
Other limitations (which may or may not apply to your implementation):
* changes made by the backend on behalf of the server must not be
included in the journal maintained by the data store
* changes have to be tracked per peer, not per data store
(required to sync with multiple servers and for unit testing of
the backend in client-test)
I'll find a
> a) we are able to get a list of records that changed
and another
> list of records deleted since last time we checked
> b) if my assumption that items not appearing in the listAllItems
> will be deleted remotely by the engine, we can ignore this deleted
> list
> c) with the changed records list, we could say last mod time is NOW
> (say, the start of sync), and set a custom field in the record to act
> as last mod time. (Will have to re-save the record locally.)
> d) with unchanged records, do nothing but extract that last mod time
> from the custom field
Instead of faking a last mod field it might be easier to implement the
EvolutionSyncSource class.
... or go to the Synthesis DB Interface directly. It's not possible with
the current SyncEvolution API, but as I said, it would be useful and I
think I know now how to expose it. What's your timeline for implementing
something?
The Synthesis DB Interface contains some support code ("binfile") which
is not used by EvolutionSyncSource. Therefore the functionality which
has to be provided by a DB backend is less than what is expected by
SyncEvolution:
* listing all items, deleted and updated items is enough (added
items are calculated automatically)
* works with data stores which have only a single "item changed
flag": this information can be passed to the Synthesis engine
once, then the flag can be reset. The engine remembers when the
item was changed and can sync the change against multiple peers.
At least that's my understanding, I haven't used the feature...
* no need to serialize items (as mentioned before)
On the other hand, because relevant features are missing (expected APIs,
native serialization of items), the SyncEvolution client-test test
framework and the backup/restore/diff feature can't be used with such a
"native Synthesis backend".
--
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.