Friday Dec 21, 2012

CalConnect Consensus Scheduling Workshop

Oracle is hosting the next Calconnect interop fest and roundtable. Both events are limited to members of the Calconnect consortium, but the workshop on consensus scheduling is open to all.

Consensus scheduling is the process by whereby a group comes to agreement on when to hold a meeting. While we all know that here are 7 things you need to know about consensus scheduling, this workshop will probably allow you to discover many more.

Friday Jul 24, 2009

Email reminders mess (progress on the horizon)

One of my desktops is a Mac Mini and recently, I started to notice that the Apple Mail program would startup by itself at what seemed like random occasions and ask me for very private information like my uid, password etc... (Thunderbird is my main client).

After exonerating my kids I figured out what was happening: I have a family calendar at an ISP who now offers CalDAV access. A few days before I started to notice the ghost Mail, I had setup the Apple iCal calendar client to show that calendar. Most of the events on that calendar have email reminders associated with them. Those reminders are generated by the ISP Server but it looks like my desktop was trying to honor those as well. Would I have configure Apple Mail properly, I would have started to receive 2 copies of each reminders.

The fact that the iCalendar specification remains silent on the subject of who (client or server) should honor VALARM with an ACTION property set to EMAIL is a pretty well known issue but I always thought it was a rather theoritical one (Lightning for example does not honor email alarms). It is the first time that I face it as an end user.

It looks like the new VALARM Extension draft is coming at about the right time for me...

Friday Oct 05, 2007

Calconnect discussions: the resource mess (booking a conference room)

Some more notes from the last Calconnect Roundtable...

The Calconnect Use Case Technical Committee presented their survey of the current state of resources in the context of a calendar application. They started by defining what they meant by resource, using the Calendaring and Scheduling Glossary of Terms definition:

Resource - Shared equipment, materials, or facilities that can be scheduled for use by calendar users.
Examples include: conference rooms, computers, audio visual equipment, and vehicles.

Then they demonstrated, using a single table, how interop is a myth when it comes to resource scheduling: after comparing the resource related attributes of 11 popular calendar products, they found that only 2 attributes were common to most of them (at least at the "conceptual" level and one of them being the name of the resource...).

The table did not include actual interop info showing how calendar client from product X could retrieve and interpret resource info from product Y but I suspect the result would have been close to 0% for most products.

But the discussion did not stay focused on the quest of a minimal interop schema (it was not the goal of the presentation anyway, its title being "Resources Revisited"). Instead it went into different directions. Just to list a few topics that were brought up:

  • Which component of the calendar ecosystem (Calendar Server, Directory,...) should offer the resource query service (e.g. "I have a meeting with 10 people, find a conference room with a projector, as close to my office as possible") ?
  • What are the client (versus server) responsibilities when it comes to finding and scheduling a resource ?
  • Should resources be represented in iCalendar objects (meetings) as a specific subcomponents (i.e. following what is currently done with the VVENUE draft) instead of just relying on things like LOCATION or ATTENDEE ?
  • Where is the boundary between an all-purpose calendaring system and a resource management system ?
  • Scheduling can be role based, hence resources can actually be people (e.g. "restaurant owner needs 3 cooks and one counter staff available on Sunday"). How do you convey that information in iCalendar objects ?

Monday Sep 24, 2007

Calconnect discussion: use of VALARM in clients: dismiss versus snooze (continued)

More on alarms (see previous post):

Snoozing an alarm - non recurring event:

It first striked me that snoozing an alarm was a pure client issue. I "snooze" a lot but in general, it is to be pinged again 1 minute before the beginning of a meeting. Apparently, other people are snoozing for much longer periods of time (e.g. one day). And indeed some popular calendar clients offer options to snooze for up to several weeks. So maybe in this type of scenario the information should be propagated to the server after all.

One simple solution is for the client to change the TRIGGER property of the corresponding VALARM to the new value (either relative or absolute) and propagate that change to the Server. A problem with changing the TRIGGER property on each snooze is that this may lead to pretty funky TRIGGER values. When displaying the event, those funky values will be displayed to the end user.
Another solution is to add an extra VALARM with a TRIGGER expressed in absolute time. This is correct from a standard point of view, but how will clients react to having multiple display alarms ? Something to experiment...
Yet another solution would be to keep the TRIGGER as is and to add a yet to be defined SNOOZEUNTIL property containing the datetime of the next time the alarm should be fired. This is what Lightning seems to be doing with their X-MOZ-SNOOZE-TIME property. Weirdly enough, this X- property is not part of the VALARM component but it is part of the main component. The advantage of this approach is that it is less likely to break existing clients.

 My preference would be to use extra VALARM to convey the snooze information as it should work today across clients.

Snoozing an alarm - recurring event: 

Out of the 3 solutions presented above for non recurring events, only the second and third make sense in the context of recurring events as the first solution (change the TRIGGER) would translate to changing the TRIGGER value for all the upcoming instances of the event. Creating an exception every time the user wants to snooze would not be acceptable either.

One thing to note about the 2 other solutions is that if multiple instances get snoozed, there is no link between the instance that triggered the original alarm and whatever information we add (SNOOZEUNTIL property or VALARM) to indicate that the alarm was snoozed. For example, if I have a recurring weekly meeting, I snooze the alarm on the first instance for 5 more weeks, then one week later, I snooze the alarm of the second instance for 1 more week. I will end up with 2 SNOOZEUNTIL properties or 2 VALARM components but I have no way of knowing which instance triggered them to be added. But do we really care ?...

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.




« February 2017