hCalendar input/output

[wsanchez@…]

It would be swell if the server could accept hCalendar input and emit hCalendar output, given the right content-type/accept headers. This would help the microformats folks use it to embed calendar data into HTML and so on.

[wsanchez@…]

The best way to implement that in our server would be to add hCalendar parsing and generation in vobject. I understand that some hCalendar generation work is already underway...

Presumably we're going to want to store the data on disk in one format (I vote for iCalendar). If we allowed the underlying data format to change, we'll need to be sure to add a MIME type property to we know it's type. No, the file extension isn't an acceptable method for determining that. Which brings up another point; if you rewrite an iCalendar file with hCalendar, you'd be unable to change the file extension, so that's a snag there as well. So I think we need only one underlying data format, for sanity. Of course that means a PUT on foo.hcal would contain iCalendar data. Not sure we can win there. Content negotiation, anyone?

So a PUT with hCalendar data will result in iCalendar data on disk. When vobject parses that iCalendar data later and generates hCalendar from it, it will probably not be possible to guarantee that it generates exactly the same bytes we started with. That's something to keep in mind in the context of ETags, which the CalDAV spec is somewhat goofy about (Cyrus will disagree about the goofy).

[drernie@…]

Yes, vObject: http://vobject.skyhouseconsulting.com/epydoc/public/vobject-module.html

is adding microformat generation in the latest build:

<http://svn.osafoundation.org/vobject/trunk/>

and I've pointed them to the Python parser for consumption:

http://microformats.org/discuss/mail/microformats-dev/2005-November/000037.html

I agree you need to normalize the on-disk format, but my main goal is to make it easty to get an hCalendar feed -- ideally with a cool stylesheet. :-)