How to deal with multiplied Kolab UIDs (Re: [Kolab-devel] RE :Re: Z-push most common issue with duplicateUID)

[Bernhard Reiter]

Am Thursday, 15. December 2011 14:25:35 schrieb Georg C. F. Greve:
> So this is definitely something that should be done by the client with the
> user credentials. On object modification/addition/deletion the client
> should:
>
>  (1) Get all objects in that user's data structure with this Kolab UID,
>                 which is a single IMAP query

Note that there are two cases for a multiplied Kolab UID:
a) a technical cause, as mentioned before one example is that the write of the 
new objects happens, but afterwards the old deletion one did not happen.

b) there is a need for human coordination, because secretary S1 entered 
something while secretary S2 entered something else at the same time.

In case of b) the two objects with the same UID must be kept by all 
non-interactive Kolab Clients.

To me it seems you are mainly talking about case a), just a few brief 
comments:

>  (2) If there are zero or one objects returned: All is well, go to (4)
>
>  (3) If there is more than one object returned:
>
>  (3a) If it is a delete operation: Set them all to \Deleted

I haven't thought through this from the IMAP point of view,
but shouldn't the adding happen before (3a) will mark something as \Deleted to 
prevent that this or another client deletes all objects when the first client
is interrupted right afterwards?

>  (3b)   Start from the last addition
>                         (= highest mod sequence / message id in folder)
>         and iterate over them backwards checking for consistency.
>
>  (3c) Break at first consistent object and use it for (4) onwards
>
>  (3d) Set all others to \Deleted with expunge_mode: delayed as
>                 suggested by Jeroen (should be possible in single command,
>                 as well, I presume)

From the point of view of Kolab in this situation always a new IMAP object
should be written and the old deleted. Also see the new 
https://roundup.kolab.org/issue4805 (Duplicated event objects gets deleted 
instead of being rewritten))

>  (4) Perform adding operation

>
>  (5) If it was a modification, delete the previous object
>
> Duplicates should then only occur as a result of interruption between (4)
> and (5), or two simultaneous operations running by two different clients.
>
> The first case ought to be resolved on next access, so perhaps a process of
>
>   (1) Get all objects in that user's data structure with this Kolab UID
>
>   (2) If there is more than one object returned:
>
>   (2a) Start from the last addition backward, use first consistent object
>
>   (2b) Set all others to \Deleted with expunge_mode: delayed
>
>   (3) Push selected object to mobile phone
>
> should also be run when an object has been modified on the server, for each
> new entry. That ought to catch virtually all cases, with a "last successful
> modification wins" approach, no?

Again, the last modification *must* not win in case b).
I probably do not see all aspect of this question, my approach indeed would 
be: If there are several objects with the same uid, and some are technical 
broken or content-identical to others:
  write a new imap object with the same id and delete the broken and idential 
  one.

If you still have several objects with the same uid (which now are technical 
correct, but have differences in content):
  If non-interactive like a mobile-phone sync:
    Leave them be and show them all. E.g. as parallel appointments
    with a prefix like "1:" "2:". If one of them gets changed, do the change
    only for this object. Do not write the prefixes to the objects.
  If interactive like Desktop or Touch clients:
    Show a "coordination needed" dialog with shows the contents diff of both 
    objects and suggests a merged variant, e.g. which will add both 
    participants or both summary texts. In addition to keep one or the others.
    Afterwards a new object with the same UID will be written and the others
    deleted.

Hope that is helpful, though it is quite brief,
Bernhard
  
-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- 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/format/attachments/20120103/4033cbca/attachment.sig>