It's been a while since I posted about CalDAV. I realized our Confluence feed was a little too verbose, and I wanted to make sure we didn't continue to spam the planet Sakai feed.
The work is coming along, though not in ways that are particularly glamorous. One of the challenges with any type of integration work is what you do about the impedance mismatches between systems that always pop up. For Sakai CalDAV integration, one example is that the CalDAV spec does not support using rich text or HTML within event titles or descriptions. It turns out there's a good reason for this: since CalDAV clients can include low-end mobile devices, the safest content is the lowest common denominator. The implication for Sakai is that we need to disable the rich text editor when we use a CalDAV backing store.
Some other examples are trickier: CalDAV supports having an attachment on a calendar event, as either binary data or a URL, but only one, not multiple attachments as the Sakai calendar does. Also, each Sakai event has an event type (Activity, Lecture, Exam, etc.) but there is no CalDAV property for this, so I'm trying to use something called an XProperty. Hopefully I'll know today if that's going to work.
My biggest unsolved problem right now is programmatically setting an access control list on each calendar. When an instructor creates a calendar, each student should have read access to it. This is supposed to be possible to specify on any compliant WebDAV server, but I'm getting hung up on what I guess is a syntactic problem. I can tell Zimbra to give read access to everyone, or to all authenticated users, but when I try to name individuals, I get "400 bad request." I'm trying to make contact with some Zimbra developers for this issue.
I'm on final approach to the Paris conference. I won't be there (I'm in Costa Rica!) but Clay Fenlason intends to set up a BoF and demo what we've done. I don't think I will have produced the end-all, be-all of calendar clients, but it should make a pretty good demo.