[Kolab-devel] Kolab 3.0: Conflict Resolution

[Christian Mollekopf]

On Monday 14 May 2012 22.39:33 Christian Mollekopf wrote:
> Hey,
> 
> After some pretty long ramblings from my side, I finally have a draft how
> Conflict Resolution might look for Kolab 3.0. You can find the description
> here:
> http://wiki.kolab.org/Conflict_Resolution#Kolab_Conflict_Resolution_Approac
> h:_Clientside_resolution
> 
> Note that the page includes a lot more info, including a complete other
> approach "Full History" which has been discarded in favor of Clientside
> resolution. If you're interested feel free to have a look around to see how
> I got here. (#Endless_Resolution_Loop and
> Kolab_Conflict_Resolution_Approach:_Full_history are chapters I spent quite
> a bit of thought on, the rest are mostly leftovers of several iterations).
> If you're just interested in the proposed solution it is safe to read only
> the _Clientside_resolution chapter.
> 
> I'm pretty happy with the approach by now, as I think it will provide what
> we need to be able to implement painless handling of conflicts, starting
> from a proper strategy to ensure that conflicts are always detected in the
> first place to a concept how to resolve conflicts using a merge (which I
> believe will do the job in 99% of the cases). Of course all of this can be
> done while guaranteeing that there is no dataloss at all (given all
> participating clients implement the necessary requirements).
> 
> Any comments are of course appreciated.

You might have noticed that my proposal is not really implementable like that 
as IMAP APPEND is not supported by CONDSTORE (only STORE and SELECT and some 
others are, god knows why).

Bummer.

The consequence is, that duplictes can and will occur on the server. I'm not 
aware of any way to technically make sure no duplicates will ever be created, 
so we just have to deal with that.
I think we can define:
* If a duplicates exists only the one with the lower UID MUST be used
* If a duplicates exists the one with the higher UID SHALL be deleted
Clients just have to check after every APPEND that they didn't create a 
duplicate, and otherwise just retry (merge and append again).

I'm not yet qute sure if also other clients may delete the duplicate, or only 
the client that created it, and how to detect exactly if a client created a 
conflict.

However, I'm working on that, so no need to give the already outdated proposal 
too much thought. Sorry for bothering you with that half baked solution.

Of course it is entierly possible that I'm just missing some part of the IMAP 
spec which would solve the CONDSTORE APPEND problem, so if you're aware of 
something like that, tell me please.

Cheers,
Christian

> 
> Cheers,
> Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120517/c94ab262/attachment.sig>