't Bijstere spoor

The last SabreDAV announcement I made here was 1.0.4, which happened in January. Just today I've released 1.0.9, so I figured it's time for a small update.

A public demo site

I've bought the sabredav.org domain, and placed a live demo on it for people to try out. Give it a shot:

• url demo.sabredav.org.

• username: testuser
• password: test

Please note that OS/X Finder will not be able to upload files here, because it uses the Chunked Transfer Encoding, which is not supported by sourceforge's webserver Nginx. Read more here.

Bugfixes

There's been a number of small(ish) bugfixes.

1. Fixed fatal error when a malformed url was called.
2. Issue 19: Better responses to HEAD requests on collections, improving compatibility with MS Office.
3. Issue 23: Fixed Allow header, improving compatibility with Evolution.
4. Issue 21: Typo.
5. Issue 27: Incorrect encoding of entities in properties.
6. Issue 29: Missing constant causing fatal error on lock requests with infinite timeouts.

So there it is. You can download the latest version on the googlecode project page.

CalDAV

CalDAV support is going well. Currently iCal, Evolution and Lightning/Sunbird are supported. If you want to test it out, be sure to download the alpha version (1.1.x), and read the related documentation.

IRC

I've also setup an irc channel on freenode.net. If you feel like idling somewhere new, head over to #sabredav.

It's been a long time coming, but I finally have some working CalDAV code. The server has been tested with iCal 3.0 and 4.0 (Leopard and Snow leopard), Sunbird 1.0 pre-release and Evolution.

My main goal is to create a general-purpose CalDAV library, rather than a consumer-ready server app. I'm hoping people will be able to use this library to enable CalDAV functionality in their existing applications.

If you're interested in hacking around or testing, you'll have to grab a copy from subversion. Full installation instructions are available. Because of the alpha-stability nature of the code data-loss can occur, so beware!

Over the past little while I've been working on a CalDAV library, and it's tough!

It appears that the spec is very much implemented with the client, rather than the server in mind. The spec writers have left no stone unturned, and it's technically possible to query the server for any odd dataset you might need. Aside from that the authors made absolutely sure there were no duplicated efforts, and built heavily upon the existing WebDAV, WebDAV ACL extensions and iCalendar.

While I generally agree it's a wise thing to not reinvent the wheel, I'm a bit of a pragmatist and feel the complexity of all these layers make it hard to understand, and must have played/will play a factor in the arguably slow adoption rate.

To keep it short, I feel the authors have over-engineered/abstracted the specification. Instead of making simple API's that work for 90% of the usecases, they have gone a much more generic route. This makes it very hard to predict how CalDAV clients will be using the server. Also, it makes it quite difficult to optimize and fit in a simple relational database or existing calendaring software. CalDAV should IMHO just have been a simple CRUD system. Advanced features and reports could have been made optional, and should have been specialized for common usecases.

Incomplete view of Web/CalDAV dependencies

This was a graph I used in an earlier post. There's actually a few more specs that are relevant to the implementor.

GroupDAV

GroupDAV deserves a mention here, as it attempts to address most of the issues I have. What it lacks is adoption from ICal, Sunbird and MS Outlook. The only issue I have is the frowned upon use of the PUT method (spec), where POST really should have been used.

Some examples

These will be highly uninteresting unless you have an intimate knowledge of the specs.

New calendars/events/todo's are created using PUT. This means the client now determines the unique id given to any of these objects. Most people will want to integrate CalDAV with systems which already have a different primary key, these people will be required maintaining 2 different id's and ensure there are never any duplicates. The id generated by the client can be any url encoded string. Note that this wouldn't have to be a problem if some POST statement would have been used.

CalDAV requires support for the expand-properties report from rfc 3253. In a nutshell the expand-properties report will look for WebDAV properties containing <DAV:href>url<DAV:/href>, follow these locally and add specified properties from these resources to the DOM. The benefit of this REPORT query is that less HTTP requests/roundtrips have to be made to make this work. The usecase for CalDAV specifically might be a lot simpler though, as it could mean something like 'get me the information of the user owning this calendar'. If it was instead simply required to add functionality that meets exactly that (and a few other usecases), it would be reasonably easy for me to write an optimized SQL query for those cases. Now I should support these lookup queries everywhere, because there's no good way to restrict how clients might use it.

CalDAV also requires fully implementing the ACL spec. The main usecase for this is calendar sharing. While the ACL specification will give you infinite complexity in how to setup your access control, it's quite a bit of work to even send back all the appropriate information and error messaging if you're not actually interested in this feature. Making ACL an optional extension to CalDAV would have been easier for implementers IMHO.