[Kolab-devel] How to deal with multiplied Kolab UIDs (Re: RE :Re: Z-push most common issue with duplicateUID)
Georg C. F. Greve
greve at kolabsys.com
Wed Jan 4 13:40:44 CET 2012
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
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
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
More information about the devel