Thursday Jun 18, 2009

Setting up a demo CalDAV account on iPhone OS 3.0

As you probably know, the new iPhone OS 3.0 is CalDAV enabled.

The default configuration panel is very simple (server name, user name, password), but it makes some assumptions that may be valid for a production system but not for a demo server:

  • use of standard ports (443 or 80),
  • ssl is the default,
  • the account url follows a fixed pattern: http(s)://<server name>/principals/users/<user name>/

Demo servers usually run on non standard port numbers and they do not always own the full namespace, leading to account urls (actually principal url) that look more like :<user  name>/

Typing this kind of url can be very tedious and error prone, especially given that the advanced configuration panel offers just a tiny text box.

Here is the simplest way that I have found so far to make the process a little bit less painful, assuming that you have a mail account configured already.

1) email the principal url to yourself

... from your regular desktop/laptop email client of course. Check that the url is valid (using a regular browser) before sending it.

The principal url will vary from servers to servers. It is the same that you may have configured if you are using the Apple iCal client (iCal --> Preferences --> Accounts --> <your CalDAV account> --> Server Settings --> Account URL).

2) copy the url from the iPhone Mail App

Go to the iPhone Mail App and open the email.

Press and hold on the url in the message.

You should be asked whether you want to Open or copy the link:

Select copy.

3) go to the CalDAV account creation panel

Settings --> Mail, Contacts, Calendars --> Add Account... --> Other --> Add CalDAV Account

4) Enter the server info

Tap on the Server field. A "Paste" button should appear on top of the text field:

Press on "Paste". The full url is shown:

This is the only trick, really: the client accepts a full url in the server name field.

5) Enter the User Name and password

Go to the User Name field. The full principal url is replaced by the server name only. This is OK:

Finally, enter your password and tap "Next" --> the client indicates "Verifying CalDAV account", then "Account verified".

You can now go to the Calendar application.

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 ?...




« June 2016