Blog

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.

First Feature Demo


Ah, there's nothing like the feeling of working software. Especially the itchy, awkward feeling of pre-alpha software.

So I have some basic things working in Sakai CalDAV integration and here's a quick screencast:
http://screencast.com/t/pnZIDaNiYQl

I've got to draw up some documentation, and then I'll be back on the blog with details.


I am getting a fairly clear sense of how CalDAV clients and servers communicate with each other. I even read the spec! (Interesting aside, one of the primary authors of the CalDAV specification is Lisa Dusseault, who is a star character in "Dreaming in Code," the story of the Chandler project. She comes across as the smartest and sanest person on the team).

Here are the design questions I am currently mulling:

  • Will the calendar store be configured Sakai-wide, per worksite, or per user per worksite?
  • How should the configuration be done?
  • How do we map between Sakai users and calendar server users?
  • What happens with a Sakai guest user who may not have a calendar server identity?
Bedework online

One of the goals of the CalDAV integration with Sakai is to test simultaneously against at least two CalDAV server implementations. If we call upon our network of volunteers, we may be able to test with more systems by the time we're finished. We're using Zimbra because that's the system Georgia Tech is rolling out, and Bedework because it's a free (as in beer and freedom) system that many in our community may be interested in trying.

The advantage of testing against more than one system from the get-go is that hopefully we will avoid building in any idiosyncrasies that arise from one particular server implementation.

I have Zimbra running on a Dell workstation from 2000 that was a "tower of power" in its day. Yesterday I took delivery of an Asus eee PC 701, a two pound notebook with at least the horsepower of the old Dell.

For the curious, here's how easy it is to get a demo of Bedework up and running. The first line will depend on your system, but this is how it works on my teeny tiny eee PC. :-D

export JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
wget http://www.bedework.org/downloads/3.4.1/quickstart-3.4.1-bin.zip
unzip quickstart-3.4.1-bin.zip
cd quickstart-3.4.1
./ant.sh hsqldb

The database log will tie up that terminal window, so open another one.

cd quickstart-3.4.1
./ant.sh tomcatstart

That's it. You access the system by opening http://<servername>:8080/bedework in a browser.

Ode to HTTP

Sometimes reverse-engineering is easier than reading the documentation.

My eyes were starting to glaze over from all the RFCs and Zimbra documents, when I realized that I've got a CalDAV server (ZCS 5.0) and I've got a CalDAV client (Apple iCal 3.0.2), so all I have to do is listen to the HTTP traffic between them and I can see immediately what happens, and when.

So I've studied a few conversations. When iCal wants to push a new event into Zimbra, it does an HTTP PUT with these contents:

header name

header value

User-Agent

DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2

Host

192.168.1.109

Authorization

Basic emFjaDpv6uivccn2lZa==

If-Match

"524-1208550558000"

Content-Type

text/calendar

Content-Length

686

Connection

close

PUT request
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//iCal 3.0//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:US/Central
BEGIN:DAYLIGHT
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
TZNAME:CDT
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
TZNAME:CST
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SEQUENCE:2
TRANSP:OPAQUE
UID:B04F5D23-CEDB-4553-A2B4-ABD387414DEF
DTSTART;TZID=US/Central:20080501T160000
DTSTAMP:20080418T202919Z
SUMMARY:movie nite
CREATED:20080418T202916Z
DTEND;TZID=US/Central:20080501T170000
END:VEVENT
END:VCALENDAR

The iCalendar format is not much fun to read, but it's not impenetrable, and there's at least one Java library for handling it that appears to have a Sakai-friendly license: http://m2.modularity.net.au/projects/ical4j/

And here's a delete operation. It's an HTTP DELETE. The request doesn't even need a body:

header name

header value

User-Agent

DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2

Host

192.168.1.109

Authorization

Basic emFjaDpv6uivccn2lZa==

If-Match

"524-1208550560000"

Content-Length

0

Connection

close

I already have some Java code (not ready to commit) that creates requests just like these. Isn't it kind of awesome how well HTTP works? Next time, I'll wax poetic about etags.

Ready to Dissect Zimbra

After considerable pushing and pulling, I've got a local instance of ZCS 5.0 running in a virtual machine of Ubuntu on my mac.

Ready to dissect CalDAV!

Testing 123

Just another post, to see if it makes it into my feed.

ciao,
Zach

Sakai CalDAV Blog

The work to integrate Sakai with CalDAV stores for calendar events is underway. I'm experimenting with the blog features of Confluence to find out if it will be suitable for communicating project news to the Sakai community.

Update: I think I have the feed thing figured out. I'll have a proper URL ready soon.