arnaudq's blog
Calconnect discussion: use of VALARM in clients: dismiss versus snooze
An interesting discussion happened during the Calconnect meeting, regarding alarms. The following post does not reflect the whole discussion but simply my understanding and experience with dealing with the problems that were raised.
Most desktop calendar clients (and now some web based calendar clients) will let you set display alarms.
The alarm is usually relative to the start of the event (e.g. 15 minutes before the beginning of a meeting). It can be dismissed or "snoozed" i.e. moved to a later time ("remind me again in 5 minutes").
On the standard size, the iCalendar specification lets you:
associate as many VALARMs as you want with a VEVENT or VTODO,
specify a TRIGGER time that can be an absolute time (e.g. "20070917T160000Z") or an offset (e.g. -PT30M) from the event's start or end,
create repeating alarms.
In a client/server model using iCalendar as the data representation and regardless of the protocol (CalDAV, WCAP, the protocol previously known as SyncML,...), what does it mean to fire, dismiss or snooze a display alarm ?
(In the following, the client can be either a desktop application or a phone/PDA. In the case of a desktop application, the client being "turned on" really means that the application is launched).
When to fire a display alarm:
If the client is turned on, the response is quite obvious: it should fire the display alarm as indicated by the TRIGGER property of the VALARM component (there might be several of them and they may be repeating).
But what if the client was not turned on at the time it should have triggered the alarm ?
The consensus seems to be that the client should trigger the alarm whenever it goes back on, even if it is after the start/end of the event. That way, the end user is notified that he may have missed something important. Of course, whenever possible, a client should offer a way to "Dismiss All" alarms so as to avoid having to acknowledge dozens of alarms when coming back from an extended leave.
Dismissing an alarm - non recurring event:
This is the most simple case: the client "should" (using quotes as this is not mandated by any protocol AFAIK) remove the corresponding VALARM component from the server's copy so that other clients (or the same client after a restart) doesn't fire the alarm again. This is a relatively lightweight operation in the case of WCAP, a little bit more heavyweight in the case of CalDAV/PPKASyncML as the whole iCalendar object (VEVENT, VTODO) needs to be transmitted back to the Server.
When multiple clients are in use (or at least running) at the same time, those clients should try to detect such a change on the server and act accordingly. For example, let's imagine a user with a desktop and a laptop, both running his favorite calendar client. Both clients are turned on and hence, both display alarm messages regarding the same set of events. Now, from his laptop, the user dismisses one alarm. This will trigger a change on the server (removal of the VALARM). If well behaved, the calendar application on the desktop should detect this change on its next sync with the server and remove the display alarm from the user's view.
As usual, this is
where it gets harder: The Mozilla Lightning
project is using an X- property (X-MOZ-LASTACK) containing a
timestamp to keep track of the last time the alarm was dismissed (acknowledged).
This X- property is part of the VALARM component. Using this X- property,
clients can simply determine that only the next instance of the TRIGGER coming after
the timestamp should be considered for display. Lightning seems to
also use this X- property for non recurring events. This has the advantage that
the VALARM information can be kept within the component. If the event is "moved forward" the alarm
can be triggered again. On the other hand, this means that all the other clients
that are not aware of this X- prop (i.e. as of today most of them) will consider that the
alarm has not been dismissed. So until this property becomes standardized, I think it is better from an interop point of view to just remove the VALARM component of non recurring events when dismissing them.
There seemed to be a consensus at Calconnect that standardizing this property would probably make sense.
Posted at 04:52PM Sep 23, 2007 by arnaudq in CalDAV | Comments[2]
Well sum'ed up!
Although I generally appreciate a formal specification of alarm dismissal and snoozing, I am still unsure whether alarm acknowledges (and alarm definitions) ought to be stored within the calendar at all. Considering you subscribe to a public conference calendar, the only chance for alarms you have is to store a copy or import it, so you could write items. On the downside: By doing so, you are decoupled from any updates... It would be really helpful to have some formal guidance how CUAs should handle user [local] data vs. shared data.
Moreover, w.r.t. recurring items, X-MOZ-LASTACK is stored inside the VALARM component of the parent item, to avoid unnecessary creation of exception/overridden items. Thus a single dismiss dismisses essentially all undismissed alarms of the recurring series (from a data model perspective). Quite some users already complained about this. Those users e.g. get three alarms of a series, dismiss only the first, but won't get the latter two again. One could argue that this is not what alarms are meant to be used for and strictly thought the user has acknowledged the item (i.e. what I did in the corresponding bug), but we have to admit that this is real life usage ;) .
Posted by Daniel Boelzle on September 28, 2007 at 01:39 PM CEST #
Funny as I wanted to add a couple of additional posts on VALARM & shared calendars, VALARM & iTIP,...
The sad part is that I don't think there is any good solution in that area.
Posted by Arnaud Quillaud on October 04, 2007 at 03:54 PM CEST #