[Kde-pim] iCalendar semantic

[Christian Mollekopf]

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.

The resource has only very limited possibilities in treating errors
since the client operation is already complete, so it basically can only
drop an operation instead of writing it to the backend. So any
consistency checks should happen as early as possible (in the client).
Kdepimlibs asserts validity for single calendar objects through the ICAL
serializer, but nothing checks calendar constraints (with the calendars
being represented by collections).

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

Cheers,
Christian

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