6.4 How syncing happens (a.k.a. David’s little CalDAV rant)

(This is probably not interesting, so you can skip this.)

CalDAV is a mess.

First off, it is based on WebDAV, which has its own fair share of problems. The main design flaw of CalDAV however, is that UID and resource name (the "filename", if you want) are two different things. I know that there are reasons for that (not everything has a UID, like timezones, and you can put several events in one resource), but this is typical over-engineering to allow some marginal use cases pretty much no one needs. Another problem is that you have to do additional round-trips to get Etag and sequence number, which makes CalDAV pretty slow.

Org-caldav takes the easy route: it assumes that every resource contains one event, and that UID and resource name are identical. In fact, Google’s CalDAV interface even enforces the latter. And while Owncloud does not enforce it, at least it just does it if you create items in its web interface.

However, the CalDAV standard does not demand this, so I guess there are servers out there with which org-caldav does not work. Patches welcome.

Now, all this would be bad enough if it weren’t for the sloppy server implementations which make implementing a CalDAV client a living hell and led to several rewrites of the code. Especially Google, the 500 pound gorilla in the room, doesn’t really care much for CalDAV. I guess they really like their own shiny REST-based calendar API better, and I can’t blame them for that.