arnaudq's blog

Tuesday Sep 25, 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 ?...

Comments:

It seems to me that it would be fairly simple to link particular snooze-times to certain instances of a recurring event/todo by simply appending a parameter with the recurrence-id to the snooze-time property. Something like
BEGIN:VALARM
TRIGGER;VALUE=DATE-TIME:19970317T133000Z
X-MOZ-SNOOZE-TIME;X-MOZ-OCCURRENCE=19970318T133000Z:19970318T143000Z
ACTION:DISPLAY
END:VALARM
(apologies for any syntax errors in that hand-crafted ICS, but you get the idea)

Posted by jminta on September 28, 2007 at 10:28 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed

Calendar

Feeds

Search

Links

Navigation

Referrers