[Kde-pim] iCalendar semantic

[Patrick Ohly]

On Mon, 2014-03-17 at 14:17 +0100, Christian Mollekopf wrote:
> 
> On Mon, Mar 17, 2014, at 01:29 PM, Patrick Ohly wrote:
> > Hello!
> > 
> 
> Hey Patrick,
> 
> > I've got a bug report
> > (https://bugs.freedesktop.org/show_bug.cgi?id=74342) and (now that I
> > started running and analyzing them myself) some failing tests around
> > iCalendar 2.0 semantics. Some of these have been known issues waiting
> > for some interested developer to deal with, but it seems to be worse
> > than I thought.
> > 
> > Anyway, the key question is: in the Akonadi architecture, which entity
> > is responsible for ensuring that a collection of calendar items meets
> > iCalendar 2.0 semantics? Is it something that resources do or is the
> > client of Akonadi responsible?
> > 
> > Specific cases that need to be handled:
> >       * Adding or updating items with some mandatory properties missing,
> >         like UID - this is the root problem of bug #74342.
> >       * Adding a new item with the same UID/RECURRENCE-ID combination as
> >         an already existing one - covered by testInsertTwice, fails with
> >         Akonadi.
> > 
> > If the user of Akonadi is responsible for ensuring unique UIDs, how can
> > this be done reliably, taking into account that multiple different
> > clients may be inserting the same item concurrently?
> > 
> 
> Neither the client not the resource should have to do UID uniqueness
> checks. UID's should simply be generated according to RFC4122 which
> basically guarantees that they are unique.

For new items, yes.

But this does not help when two different apps are trying to import the
same existing event received from somewhere concurrently. When an app
imports an event, it must:
     1. Read the UID/RECURRENCE-IDs of all existing items.
     2. Check that the new item does not already exist.
     3. Send the new item to Akonadi.

There is a race condition because the same item might already have been
imported between step 1 and 3.

I know that this is a somewhat contrived situation; it just illustrates
that expecting the client to assure correctness is not reliable.

> But IMO the UID issue is solved by using proper RFC4122 based UID's, and
> the second case is a corner case that IMO doesn't need to be handled
> specifically (and otherwise the client would be responsible as well).

I agree that sometimes one simply has to concentrate on more realistic
scenarios first, but I prefer to design systems such that they can be
fixed later.

Bye, Patrick

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/