Thursday Mar 12, 2009

VTODO with DUE date in other clients

To finish on the VTODO with DUE date topic, I've looked at some "not yet CalDAV enabled" clients.

Microsoft Outlook

In Outlook (more precisely, in Outlook 2003), you can create a task with a start and/or due date (no time). This task can have an associated alarm, which is specified as a date and time. This removes the ambiguity of using relative alarms, found in both Apple iCal and Lightning. It also allows to have a task with no start or due date and just an alarm.

eM Client

Using the eM Client , you can also create tasks. Both start and due date/time must be specified. This task can have an associated alarm, specified as a date and time.

Note: the eM client is CalDAV enabled for VEVENT but not yet for VTODOs.


Evolution offers all combinations of start/due, using either date or date and time. Nevertheless, I could not find a way to set an alarm which is quite strange.

Note: Evolution is CalDAV enabled for VEVENT but not for VTODOs.

Sun Convergence

The Sun Convergence web client exposes only an optional due date (or date time). The associated email or sms alarm can be either relative or absolute ("On Date" in the pulldown below):

Sunday Sep 23, 2007

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. 

Dismissing an alarm - recurring event:

As usual, this is where it gets harder:

  • Completely removing the VALARM on dismiss would correspond to not having any alarm for all the upcoming instances of the recurring event... Definitely not what the end user wants to do
  • Adding a VEVENT exception with no VALARM each time the user dismiss once instance would be very dangerous in terms of performance, usability and interoperability.
  • Not acting on the representation of the alarm means that on the next restart, the client will have no way of knowing whether it should display the last past alarm or the next scheduled one.


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.
There seemed to be a consensus at Calconnect that standardizing this property would probably make sense.

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.

Wednesday Jun 06, 2007

new wcap based server

Several calendar server projects have added (partial) support for Sun WCAP protocol. The latest I have found (here) is the Fin Calendar Server. While WCAP has been around for almost 10 years, those alternative implementations have started to appear only recently.

The fact that several fat calendar clients (Sun Outlook Connector, Thunderbird + Lightning, Evolution, Kontact, ...) are now WCAP aware is probably the main reason for this sudden interest. Its very simple design makes it also quite easy to understand and implement.

Saturday May 26, 2007

Outlook + Exchange changing their freebusy access model

Interesting to see that Microsoft Outlook + Exchange is changing their freebusy access model toward using a web service (whatever this may mean) instead of relying on public folder synchronization.

Unfortunately, I'm having a hard time finding the specification for this web service. But apparently, it allows for some kind of point to point cross domain freebusy queries.

Although it is not officially part of the product, we do have a freebusy gateway allowing Sun Calendar users to see the free busy information of Exchange users. We've tried to prototype the opposite (Exchange users accessing Sun Calendar users freebusy info) for some time but the lack of API on the Exchange side made us postpone this project.

This new web service kind of changes our perspective although I'm not sure it is for the best. Even if the web service is published, we may also have to deal with autodiscovery mechanism.

That said, most of the customers migrating off Exchange to our Comms Suite usually run pretty old versions of Exchange. So we may not hear about this web service for long.




« June 2016