Blog posts tagged "standards"

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

In support of standards

January 26th, 2003

Mark Pilgrim is dangerous; a good writer and deep thinker with a mind blowing amount of whuffie. So when he starts talking about competitive advantage of ignoring standards, unfortunately people hear more then I think he said. There seems to an anti-standards wind blowing through the blogosphere this morning, and its kind of alarming. I would like to think about alternatives.

Capitalist Mindset

In ensuring discussion all sorts of wonderfully capitalist metaphors about accured interest, natural costs, and competive advantage have floated to the surface. So here are a couple of more, XML::RSS has an overwhelming mindshare, and namespace lockout in the Perl community, giving us a virtual monopoly. Its true Amphetadesk, an RSS aggregator written in Perl, chose to go its owny way, and perhaps that proves Mark’s point for the niche market of aggregators.(which is a loud, and very profile market I give you that) But there is still a lot of demand from people who aren’t aggregators and I feel like XML::RSS should be able to do something with its market power. Think Microsoft, but in a good way :)

A few thoughts on making things better

  1. Help people produce valid feeds. XML::RSS was one of the biggest offenders in this regard. It actively worked against people, unescaping their HTML entities, and not re-escaping this. This has been fixed in the next release.
     
  2. Give helpful error messages when parsing fails. In the long term it would be nice to port the RSS Validator to be part of the toolkit to tell people exactly whats wrong with the feed. Feed consumers might be more outspoken if they knew why the feed broke and whose fault it was. Despite my minor gripes about it, the RSS Validator is a very powerful tool.
     
  3. Until we port the Validator, perhaps when RSS hits a parsing error, we can say.
    RSS parsing error on line 345, column 12 [like we do now, plus]
    For more info on why parsing failed see: http://feeds.archive.org/validator/check?url=http://someurl/index.rdf
  4. Now that XML::RSS has a webpage, we should be putting up articles, and links to articles showing best practice, and talking about pitfalls.
     
  5. Other ideas?

What are the toolkits?

What are people using to parse RSS these days? Python has Mark N.'s RSS.py and Mark P.'s rss_parsrer, PHP has hundreds of solutions, and lots of doing it by hand, but I think PHP-RSS was close to a standard, and I think MagpieRSS is gaining acceptance. What do people use in Java? In C? In those other languages? What does NetNewsWire use? And all these Windows aggregators?

Yup still, geeking out on RSS despite what I said yesterday.

Tagged: Uncategorized , , ,

Process & Collaboration

November 1st, 2002

Kendall’s latest, Community and Specifications includes

Megginson’s Four Laws of writing successful specs:
  1. Simplicity succeeds
  2. Process is poison
  3. Code first, then specify
  4. Almost every new spec fails anyway
(as the author of SAX presumably he knows of what he speaks)

In a similar vein, the David Clark quote I had as my sig for years (and am thinking of reviving)

“we reject kings, presidents and voting. we believe in rough consensus and running code.”
Been struggling with this of late, particularily in online organizing which exagerates communication problems; walking the line between enough process to stay transparent, and enough flexibility to stay open.

Tagged: Uncategorized , , , ,