Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
hCalendar input/output #19
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@… originally submitted this as comment:4:ticket:19
is adding microformat generation in the latest build:
and I've pointed them to the Python parser for consumption:
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. :-)