Blog posts tagged "caldav"

  • August 16, 2008

    Spike in CalDAV job searches.

    I’m seeing an interesting spike in folks looking for resumes with CalDAV on them, 37 queries for “caldav inurl:resume” in the last week. (and I should probably take it off mine as the state of the art has progressed while I’ve been away)

    + 0. (Aside , , , )

RFC 4791, or CalDAV to its friends

July 29th, 2008

CalDAV is now available from Google Calendar and Zimbra.

At times I’ve been CalDAV’s biggest fan. A calendaring protocol which finally stopped actively pretending the Web didn’t exist (I’m looking at you IETF CalSch WG)! But it does seem like its been a hard slog to implement. Keeping my fingers crossed for the future.

(pointed out to me that merely because I found out about Zimbra’s CalDAV support last week at OSCON, doesn’t mean it hasn’t been available since January, mea culpa)

Collaboration, an open source CalDav from Apple

August 8th, 2006

I missed it, I’d even seen the inimitable Wilfredo on the lists and it went right by me, but I ran into Nat last night at Buzz’s WWDC party, and he rather riveted my attention (as I think he knew he would), that iCalServer announced yesterday? Turns out its an open source CalDav server, written in Python (Twisted), Apache 2.0 license, with great unit test coverage. (which bodes well for the trial by fire known as interop)

Btw. Collaboration’s homepage seems to be a Trac install which is sputtering, and crying. Under load?

update: Um, and how long as Cyrus Daboo been signing his emails “Apple Software Engineer”? Yup, I was asleep.

update 2: wsz confirms trac unhappiness (and my Twisted inside observation), I guess I just got in in time, if you email me, I’ll send you a tarball of the src.

Tagged: Uncategorized , , ,

The Lost Skeleton of CalDAVra

April 18th, 2004

CalDAV: Calendar Server Extensions for WebDAV by Lisa Dusseault of OSAF/Chandler (not to mention WebDAV, XMPP [aka Jabber], IMAPext, and who knows what else!) is the most exciting new calendar standard in years. It always seemed strange to me that the Calsch working group chose not to build on top of what is clearly the protocol success story of the last decade and a half, HTTP.

In the five years since WebDAV was standardized, at least three groups have used WebDAV as a basis to provide Internet calendar access with a minimum of development effort…
Because WebDAV gets you some wonderful things. Built in synchronization, built in security model (WebDAV ACL + TLS), built in authentication (SASL), high quality, wildly popular, open source, freely available server (Apache), large number of existing, high quality, freely available libraries (e.g. neon), large deploy base of WebDAV aware clients (every MacOSX and Windows XP box to start with), graceful degradation to the really ridiculously huge number of clients with a HTTP stack, the list goes on. Not to mention the space is hopping; lots of people working on improving performance, security and implementations of WebDAV, and high profile projects like Subversion validating the technology.

Three groups including Apple we might point out, the only company to successfully move calendaring standards forward to date.

How Does It Work?

CalDAV proposes a relatively simple solution of nested collections, a calendar collection, for each calendar an event collection, for each event collection, subcollections for the various iCalendar objects (events, todos, freebusy, journals and alarms) plus an additional collection to handle invites (iTIP)

Now doesn’t that sound refreshingly easy and level headed compared to iRIP (prophetically named), and the many year ordeal of CAP and its several stalled attempts, and weird technology choices like BEEP? You almost feel like you could sit down and write it in an evening (install mod_dav, make dirs, and go!)

Some Caveats

Well unfortunately its not quite that simple. There is language in the proposal about handling recurrence calculations which makes sense, and handling fanout which is that same damn tendency to roll scheduling into calendaring which means that nothing ever gets done. (not to mention the weird idea of backchanneling alarms from the web server to the client via XMPP) I say get a decent calendar store implemented, then talk scheduling.

Its also relies on the ordered collections extension to WebDAV (approved Thursday before last1), WebDAV ACL, and suggests DeltaV. All of which adds up to that same feeling of specification creep that we’ve seen in the XML world (think XML Schema). The problem with spec creep is it raises the bar to open source development in favor of corporate solutions, and precludes later creativity.

Still at the end of the day you would have a calendar store that supported group collaboration, unique URIs per event and calendar (really a whole RESTful webservice API), offlining, and was easy to integrate with the current crop of clients and server side implementations (at least the open source ones). And it would probably be equally applicable to the work the RDF Calendar Taskforce is doing.

I’m terribly excited about calendaring for the first time in years (Sunbird is helping as well, have you seen its nifty pub/sub over HTTP feature?)

Why am I mentioning this all now?

Because the specification is set to expire two weeks from now on May 1st, and I’m hoping it won’t die.

update: When I read over the document on more time, I noticed that notifications (aforementioned iTIP and “weird backchanneling”) are noted as an optional feature; not all event sources will be calendaring sources. Right on.

1 Not to be confused with Thursday Next