Summary: [Watching 1364] SyncML server: conflict resolution
Classification: MeeGo Platform
Product: OS Middleware
Status: WAITING FOR UPSTREAM
Estimated Hours: 0.0
Patrick please focus on bug#1364, I will keep this updated. Not propose it to
be MeeGo-1.0 blocker, for it is not a blocker issue.
Description From pohly 2010-02-12 08:39:48 PST (-) [reply]
Steps to reproduce:
- setup SyncEvolution as client of a SyncEvolution
- get client and server in sync with a single task
- modify task on client and server
- sync again
During each sync, client and server swap their items. They are never really in
Either the server should preserve one task during the conflict resolution or
both, but not permanently send data around.
Might be possible to reproduce with other data, not checked yet.
------- Comment #1 From pohly 2010-02-12 08:42:37 PST (-) [reply] -------
This happened while doing slow syncs. With two-way syncs, conflict resolution
preserves only one task, as intended.
Nevertheless, slow sync should have worked, too.
------- Comment #2 From pohly 2010-04-19 08:29:07 PST (-) [reply] -------
This can be simplified:
- clear all items on a server which uses the file backend
- slow sync with one item on client A
- modify item on client A so that a key element differs (like SUMMARY in task)
- slow sync again
- client and server in sync, either with one item or two
- server has two items, client one (the unmodified one from the initial sync)
The root cause is that the server treats these two items as different when
using the file backend, because neither that backend nor the engine know about
the significance of the UID property, which happens to be identical here.
In the second slow sync, it sends an <Add> command with the item that it had
from the initial sync. The client then turns the <Add> into a <Replace> of
item that it just sent to the server, overwriting the local, more recent data
with the older copy from the server.
The client uses the EDS backend, which detects that the new item from the
server has the same UID as a local item, and therefore it *replaces* that item
instead of adding it anew.
IMHO the correct solution would be for the server to detect that two
conflicting items have the same UID. The UID of the item on the server then
must be replaced with something which satisfies the iCalendar 2.0 "globally
unique" criteria before it is sent to the client in an <Add>. Or the property
must be cleared, which will cause the client to create a value.
I have no idea how to implement either one or the other, though.
Solutions which don't work:
- Compare only the UID property. A) we don't know whether the client really
provides a stable, globally unique UID and b) we would end up with only
one item even when both items were modified and thus should both be
- Don't store UID on the server. We want it there for backup/restore of
iCalendar 2.0 clients.
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.