[Kolab-devel] Kolab 3.0: Conflict Resolution

[Christian Mollekopf]

Hey,

I overhauled the proposal to not use CONDSTORE at all and cleaned the page up, 
you can find the current state here:

http://wiki.kolab.org/Conflict_Resolution#Kolab_IMAP_Conflict_Resolution

I tried writing concept down in a more comprehensible way, but it's still 
somewhat complex, so if you have suggestions how to structure it better, or 
can tell me what is unclear, that would help me to improve it.

Open concerns/problems can be found here:
http://wiki.kolab.org/Conflict_Resolution#Concerns.2FProblems

Cheers,
Christian

On Thursday 17 May 2012 23.57:37 Christian Mollekopf wrote:
> 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_Approa
> > c
> > 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/20120523/1bcede64/attachment.sig>