Evolution

Novell Evolution is available in most Linux distributions. The CalDAV support was supposedly written in a frenzy of hacking one day when the draft specification was at around revision 8. As a result there was little in the way of a repository available to test against until recently.

1. Type:CalDAV
2. Name:Give the calendar a local name
3. URL:caldav://server.domain.name/caldav.php/$username/
4. Use SSL:if your server is using SSL you should check this, but there may be bugs in Evolution's handling of SSL.
5. Username:$username

If you have problems with Evolution, you will need to quit evolution, remove the cache file which will be in ~/.evolution/cache/calendar/ and restart. If you still have problems try doing that, but killing evolution-data-server in addition.

Sometimes evolution writes error messages into the cache file, so if you have ongoing problems you may want to take a look inside that.

There are some quirks with Evolution's handling of CalDAV too, so perhaps take a look at the following bugs:

• New appointments disappear for 1 minute, and then reappear
• Support Response with Relative URLs

Hopefully those will be fixed before too long...

Sunbird / Lightning

The Mozilla calendar project offers their calendar under two different names: Sunbird is a standalone calendar application, and Lightning is a Thunderbird extension. The two are essentially the same, as far as RSCDS is concerned, and these instructions should work for either of them.

1. Select "New Calendar" from the "File" menu.
2. Choose "On the Network" (click "Next")
3. Choose a format of "CalDAV" and enter a URL like: "caldav://calendar.example.net/caldav.php/username/" (click "Next")
4. Give the calendar an appropriate display name, and choose a colour for events on this calendar. (click "Next")
5. click "Finish"

At version 0.3 the Mozilla calendar does not automatically refresh the calendar view, so if someone else has added a meeting you will have to manually refresh the view to see that.

It is early days yet for the Mozilla calendar in it's current incarnation so no doubt there are other quirks with Mozilla's handling of CalDAV too, so perhaps take a look at their bugzilla.

Mulberry

Mulberry is the most well-behaved of the applications I have been able to use. It does have some bugs, however, and a particular annoyance around it's use of non-standard names for time zones. Mulberry is the only client I have used so far which can issue a MKCALENDAR command or which will display a hierarchy of calendars from one configured URL.

1. Select "Preferences" from the "File" menu.
2. Choose the "Accounts" tab
3. Select "New" from the "Account" drop-down and a "Create New Account" dialog will appear.
4. Enter a name for the account, choose "CalDAV Calendar" for the type and click "OK"
5. In the "Server" field enter the domain name of your CalDAV server, such as "calendar.example.net"
6. In the "Authentication" pane of the "Accounts" tab, enter your username.
7. In the "Options" pane of the "Accounts" tab, enter the path, which should be "/caldav.php/"
8. "OK" the preferences dialog
9. A list of the users and resources which you are allowed to access should appear. Some may contain calendars.
10. If you don't already have a calendar for your own user, ensure your username is highlighted and choose "Create" from the "Calendar" menu.
11. Once you have a calendar created, you need to subscribe to it. One way is to right-click on it and choose 'Subscribe'.

Unfortunately Mulberry is not open-source, though it is free, so we must wait on the developer to fix the user interface niggles when he gets around to it.

Note that Mulberry has a complex user interface. When I wrote this I went back into Mulberry and initially thought that RSCDS had regressed somewhat and that these instructions didn't exactly work... :-) It turned out that these instructions worked just fine when I followed them to the letter the next day. Go figure. I think I need to record some screenshots of this one...

Cross-client Interoperability Considerations

If you intend to have users accessing the Really Simple CalDAV Store with more than one client then you should attempt to structure the URLs which they use to access the system in the way that Mulberry does it.

Basically, Mulberry breaks the URL into three parts:

• The host name
• The root path
• Calendar namespace

The host name is, of course, up to you. The 'root path' should be /caldav.php/ and anything following that is the calendar namespace.

Within the calendar namespace RSCDS uses the first element of the path as the user or resource name, so that a client connecting at the root path can see all of the (accessible) users and resources available to them (Mulberry displays this hierarchy) with any calendars below that.

Effectively this means that in Evolution, Sunbird and Lightning you should really specify a calendar URL which is something like:

caldav://calendar.example.net/caldav.php/username/home/

Then, when more calendar client software sees it as useful to be able to browse that hierarchy, you won't be up for any heavy database manipulation.

I may well enforce this standard in some way before release 1.0, as well as auto-creating the collection records when Evolution, Lightning or Sunbird attempt to store to a non-existent collection.