I attended part of the CalConnect roundtable in Cambridge this week, had some great discussions and also got to see the group’s reaction to CalAtom. It was met with very mixed reactions and we definitely left a little bruised but I think there is some real potential and interest there.
Anyway this post wasn’t intended to be about CalAtom. Instead it is on freebusy lookups, i.e. how do I find out when you are available to meet. It was pointed out to me that one of the first interoperability aspects that any calendaring standard faces is to figure out when you are free so that I can schedule a meeting with you. If that can be accomplished then passing around iCal files in email messages can get us a first stab at interoperability. I can see when you are free, send you a meeting invitation, you can accept it and I get told you accepted. Not too shabby, although admittedly a long long way from having this work with any calendaring client server combo. It’s surprising that an existing standard for this doesn’t exist yet, but having researched some implementations I presently cannot find one. Please post responses if you know of one that I have missed.
I then looked in detail at both Google’s approach and CalDav. I first looked at what google had done. They provide a “projection” for free-busy. You can get your free-busy back as a feed, here’s a snippet.
<snip/>.....I removed the feed header and shortened the urls in one or two places as well
<link rel="self" href="http://www.google.com/calendar/fee8487fd8megmo"/>
<link rel="self" href="http://www.google50eotvfa8qgronj9oje08"/>
Now I am a BIG BIG fan of ATOM, but there is a time and a place. On the plus side this was really easy to do and with any old xml parser I can make sense of it. I should also have been able to use standard atom parsers with it, but…. Well, first off this is not valid atom. Any atom parser will barf at this as it doesn’t provide a title for the entries. It is also extremely verbose containing information that is not needed by clients that are only interested in your free time. Contrast it with a similar ical representation.
hmmm, not a great start, so next up was CalDav. The relevant section is 7.9 and if we ignore some complexity due to depth and a few other things and instead head straight onto the example, then this seems much more reasonable, very straightforward. On deeper examination though, the first thing that stands out is the use of the REPORT method. Ignoring very valid firewall concerns and ploughing straight into using it I first went in search of a java library to use. The standard library of choice for the java programmer when using http is the apache commons httpclient. Uh oh!, so no luck there. So off to google which eventually leads me to the Slide WebDav client and a solution, yeh!. It’s slightly concerning though to see that it has not been updated since 2004 and more worrisome that it still depends on a version of httpclient that was end of life’d on 27th Feb 2006. But let’s assume that this works, onto the next bit if trickery, how to parse the response. Writing a custom parser seems wrong, someone must have done this, so off to google again and I find iCal4J, yippeeee! now all I have to do is learn how to use it and ensure that I can usher this licence past my employer’s legal department and I am flying. What’s that? you want to also do this in php and ruby? and you don’t know of any libraries available for those languages?
This is too hard, too hard. There are plenty of examples of complicated http based api’s and ALL of them, ALL of them are easier to consume than this, and why is this? It’s because they use standard http verbs that all the language http utilities support and that they represent their data in a format that is accessible by parsers that all the languages support.
Contrast this with the following approach (that I will submit for discussion to the CalDav mailing list).
GET /bernard/work/freebusy?start=20060104T140000Z&end= 20060105T220000Z
HTTP/1.1 200 OK
Date: Fri, 11 Nov 2006 09:32:12 GMT
<dtstart> 20060104T140000Z </dtstart>
<dtend> 20060105T220000Z </dtend>
As a consumer I can now use HttpClient and the bundled xml parser in java, that I have used a thousand times before, done.
This has certainly been an interesting exercise for me. One of the claims I had leveled at CalDav, in an attempt to justify CalAtom, is that CalDav was just too hard. I stand by that claim. For a product group to incorporate just the freetime lookup it seems they have to convince management that it is ok to depend on a end of life’d jar file, that it really isn’t too hard to write or learn a custom parser for some proprietary data format and that as other programming languages gain popularity that there will, of course, be the base utilities in those languages to also use these features. I think that this is presently a very hard sell.
CalDav may indeed lead to a protocol that allows calendaring systems to interoperate with each other, but I wonder whether that’s enough. To be successful doesn’t it also need to interoperate with emerging web applications? and, more importantly, be consumable in a similar way? In sampling many of the current approaches there are clear patterns emerging, namely the use of http 1.1 methods and xml/json data packets. These patterns are strongly supported in all the major languages and will continue to be for the foreseeable future (this is where it’s presently at).
With the majority of http applications heading down a different path, are the custom parsers, end of life’d jars and special firewall compensations, that CalDav requires, really going to be tolerated? I’m not sure, but all this seems to beg the question “what’s so special about calendaring?” 30Boxes, google, evdb, yahoo nothing?