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)
> > 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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
