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 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.</p>

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.