Skip to content

iCalendar 2.0 + Detached Recurrences

“What the heck are detached recurrences?” and “why should I care?” might be your first reaction when reading the title. If you work in a corporate environment and have to attend regular meetings, then chances are high that you have some of those beasts in your calendar. When a meeting is canceled for a specific day, that exception can be stored as part of the original event description. But when the start/end time, description (meeting agenda!), list of attendees, etc. for a particular meeting instance is changed, then this additional information is stored in a detached recurrence which overrides the regular instance of the event.

This additional information can be essential for not missing a meeting, so anyone synchronizing his calendar or writing software which is used for that purpose should care. Neither SyncEvolution nor the SyncML servers it is commonly used with supported detached recurrence – until now. This has always been a thorn in my side, so it is with great pleasure that I can announce that 0.8 in combination with ScheduleWorld will finally synchronize detached recurrences. Both client and server required changes; I had to nudge Mark a bit until before he started working on it, but now that it is in place we are glad that we did it. In the remainder of this post I’ll give you a bit more background information.

iCalendar 2.0 + SyncML

The way how iCalendar 2.0 represents a recurring event is via a VEVENT’s RRULE property. This describes how the event repeats. A program calculating all occurrences evaluates that rule and then removes those instances which match the exceptions specified via the EXRULE or EXDATE properties.

A detached recurrence (sometimes also called “child event”) is stored as another VEVENT with the same UID as the parent event and a additional RECURRENCE-ID. This ID specifies which of the regular occurrences is overridden by the child event. Because the child is a normal VEVENT, all of the event properties can be specified independently of the parent.

In SyncML there are two ways of sending information about a recurring event and its exceptions: all VEVENTs with the same UID in the same item, or one VEVENT per item. After asking around among SyncML server developers it turned out that ScheduleWorld and Synthesis favored the “one VEVENT per item” approach because it is closer to the way how events are synchronized so far. It therefore has a chance to work even with servers which do not know the special semantic, as long as they preserve the relevant properties. This approach is what SyncEvolution and ScheduleWorld implement now.

Ordering of related VEVENTs

The ordering of these related items is important: ScheduleWorld must know the parent event before it can store the children. SyncEvolution takes care of sending items in the right order. Likewise, Evolution gets confused if a parent is added after its children: the parent event is added and stored in the calendar file with the original UID, but it cannot be retrieved under that UID until the data server is restarted. ScheduleWorld gets the order right, but because SyncEvolution is meant to also work with dumb servers (for example, a file sync source which knows nothing about the content of items), it works around this limitation by temporarily removing the children, adding the parent, then updating the parent with its children.

Updating/removing parent and children

ScheduleWorld cannot store children without a parent, so deleting the parent also removes all children. Evolution itself does the same, so normally everything works as expected. Now suppose that a dumb server tells SyncEvolution to remove only the parent. One solution would be to delete also the children, but then client and server would be out of sync. I decided to trick Evolution once more: because the API call to remove the parent automatically removes the children, they are saved by SyncEvolution before making that call and re-added afterwards. This leads to a slightly inconsistent state of the calendar, but the Evolution GUI copes and displays the children – poor orphans, you are not forgotten!

Whether modifications of a parent or child lead to an update of all related events is up to the client and server implementation. At worst it will lead to some extra traffic when items are resend although their content hasn’t changed. SyncEvolution can update both parent and children if asked to by the SyncML server.

Other SyncML servers

I’m not aware of any other SyncML server supporting detached recurrences, although there are mobile phones (like some Nokia models) which support them via a X-RECURRENCE-ID extension to vCalendar 1.0. Together with insufficient support for time zones, this looks like a rather significant gap for SyncML-based calendar synchronization compared to proprietary solutions. Hopefully SyncML server vendors will wake up and do something about it…

{ 3 } Trackbacks

  1. [...] support for detached recurrences (aka modified instances of a recurring event). Requires a SyncML server which supports this. [...]

  2. [...] of the new features in 0.8, detached recurrences, required different updating of events in a calendar. As it turned out during additional tests, [...]

  3. [...] Evolution iCalendar Two Buffer Overflow Vulnerabilities … Saved by lavishsara on Wed 03-12-2008 iCalendar 2.0 + Detached Recurrences Saved by onomark on Mon 17-11-2008 We’ve added some iCal views to BBC Programmes Saved by [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *