[Kolab-devel] RE :Re: Z-push most common issue with duplicateUID

[Jeroen van Meeuwen (Kolab Systems)]

On 2011-12-15 13:25, Georg C. F. Greve wrote:
> On Thursday 15 December 2011 13.02:12 ABBAS Alain wrote:
>> Perhaps a command tool to check the groupware folders and eliminate
>> dupplicates kolab Uids of an account should be well ?
>
> That would cause all sorts of security issues and concerns, as it 
> would be
> some daemon/regular task running with some kind of administrator 
> privileges
> against the server.
>

Aside from that, even if it were to operate against the filesystem or 
something;

It must then also have conflicting edit resolution logic, which may 
just as well be made available to the clients that should actually 
perform the operation.

> 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
>

This is only true with, for example, an event update, but moving from 
one folder to another could cause duplicate <uid /> objects to exist in 
different folders, causing it to not be discovered by a single query.

>  (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
>
>  (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)
>

The flagging as deleted is possible in one command.

Any EXPUNGE is a separate client->server call, but since it may be 
issued by any client at any point, beyond the control of the application 
detecting any sort of duplicate or conflict, you would want the 
server-side setting expunge_mode set to delayed to at least preserve an 
original copy on disk.

>  (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?
>

I think all of this logic is somewhere in the KDE PIM stack already, 
no? The online but-not-always-so-online (disconnected) IMAP client that 
is Kontact supposedly has to deal with many conflict scenarios loads of 
times.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08