Hello!
Congwu has made great progress in implementing the Evolution Data Server
API changes for safe atomic updates of items in the server (see my posts
on the Evolution hackers list).
The API adds a revision check to the EDS backend that (if requested by
the client) aborts an update or item delete if the check fails because
some other EDS client modified the item in the meantime.
That raises the question: how do we handle a conflict in SyncEvolution
once it was detected?
For "server delete/client update" conflicts I think we should refuse the
delete and in the next sync, send the item as updated.
For "server update/client update" conflicts it becomes more difficult.
If we send a temporary error code to the server and then an update in
the next sync ourselves, will the server understand? Should we do the
merging ourselves, even on clients?
The Synthesis engine already supports that (receive item from server,
parse server item into field list, retrieve item from DB, parse DB item
into field list, merge, store back into DB). In this scenario we could
redo the merging. But I am not sure right now whether we use this, nor
what the API could look like for redoing the merge. We should use this
feature (it allows preserving local properties), but we don't have tests
for it.
I'd like to see tests for atomic updates be added first:
* In Client::Source, open two sources and simulate the two kinds
of conflicts. The source which runs into a conflict should
return a suitable error (TBD) instead of overwriting more recent
data.
* In Client::Sync, devise an injection mechanism (possibly hooked
into the source progress events) which injects conflicting
changes when the sync is already running.
These tests should fail for simple SyncSource's which don't support
atomic updates (yet) and later pass once we updated the Evolution
backends; thus they have to be enabled separately in the
ClientTestConfig with "off" being the default.
--
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
