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

[Georg C. F. Greve]

On Wednesday 04 January 2012 09.51:56 Bernhard Reiter wrote:
> I believe several times a week for a productive installation 
> in a 500 person organisation in the secretary scenario.

This seems a statistically interesting claim.

Let's take a step back:

We have the scenario of an event seeing two subsequent edits. Typically this 
means the second edit *should* overwrite the first, because something has 
changed that should now be recorded in the event.

The exception to this rule is where the edits originated with separate people 
who were unaware of the other person editing the event and where the first edit 
contains irretrievable information different from the second edit that must 
under no circumstances be lost and cannot be re-added.

So, the case has the following prerequisites of occurring:

 (0) A and B are both equally entitled to edit the meeting,
	so are either participant or organizer

 (1) A is editing first, B is editing second without seeing A's edits

 (2) The edits of B are not the same as those made by A
	(i.e. a change of rooms for the event, or a change of timing)

 (3) Where (2) is not true and they edited the same property:
	B did not have better information than A when editing
	(i.e. a subsequent change to the event details)

 (4) The information of A is irretrievable, so A cannot re-add it upon
	seeing an overwriting edit by B or has no way of noticing.

As to (0): Any organization with more than one meeting per week for which all 
people are participants and these meetings *not* being organized by a 
dedicated group of people is likely very small.

Typically, with growing size of organization, such tasks would be assigned to 
dedicated personnel for large meetings, or left up to working groups for 
smaller meetings.

So no matter what the organization size, it seems unlikely more than 20 people 
would ever reasonably edit a single event. A more realistic number would be 5, 
as meetings of departments would for instance be organized by the department 
head and 2-4 additional personnel.

The likelihood of (1) is governed by synchronization interval, which will be 
in the are of 1 hour to 5 minutes, depending on the situation, going on "for 
all intents and purposes instantaneous" for installations that use IMAP IDLE.

So let's take something like 30 minute intervals.

One could of course argue that setting up your client *not* to push changes 
immediately and to have such long synchronization intervals is a broken setup, 
and that any software can be set up in ways that it will no longer work, but 
for the sake of the argument, let's assume 30 minutes.

Depending on how clients are synchronized it can be anywhere between 1 minute 
or 59 minutes for synchronization to occur, but the average will be around 30 
then which would give the average working week in the area of 80+ time slices. 

So assuming a second edit happens within the same day, the probability of a 
conflict could be 6%. For the whole week the chance of two edits conflicting is 
in the area of 1,3%. Naturally the more people edit a single event, the larger 
the chance of conflict becomes -- for 10 people editing an event within the 
same week, the probability for one conflict to occur from this should be in the 
area of 1.1%.

The question is: How many events are edited by 10 people within a single week?

For there to be "several occurrences per week" of this happening, there would 
have to be hundreds of such events. And this is not even taking into account 
(2), (3) and (4) which will likely introduce a substantial reduction in 
likelihood of two conflicting edits actually causing trouble.


Viewing it from the other side, however, if we assume that 10 people are 
reasonably expected to edit an event within a single week, in an organization 
of active smart phone users this would mean that up to 10 copies of this event 
are now on the server, all representing different edits of the same event, 
which are being hit by Kontact when its user tries to edit this same event.

Since we have hundreds of these events, that means we now have hundreds of 
events with several copies, some edits representing actual updates, some 
representing additional information.

That doesn't seem very sustainable to me.


In my experience most people will just click on "get out of my face, give me 
the last copy and delete the rest" in 99% of all cases. Where that is not 
true, intelligent usage of the deleted flag & backups can save the day.

Incurring the "pop-up hell" usability penalty for all users is a steep price 
for an inferior solution, IMHO. And I have ever only seen it occur not because 
a second person edited something, but because there was some problem in the 
network and consequently with synchronization, and it has been supremely 
annoying every single time.

That said, on top of the "flag as delete +backup/restore" approach there are 
some things we can do to mitigate potential confusion and error on the side of 
the user, such as:

 * We could just display author & date of the last change so people easily
   know who overwrote their change and let people sort it out amongst
   themselves, as there is likely a situation that requires human interaction;

 * Clients that are on line can check with the server whether the event has
    been modified before saving it, informing the user of a conflicting edit
    that has occurred in the meantime;

 * Clients that are off line and find that the event has been modified by
    someone else when coming back on line (and only then: so modification,
    and by a different person) can then have the latest edit prevail, but email
    the author(s) of the second to last edit(s) with an update notice on the
    even that has overwritten their changes, attaching their edit so nothing
    is lost.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve