To this end, ctalbert and I have been talking about the idea of
throwing together a very basic web-based protocol handler app which
we would offer to the public after M8 and until we get at least one
or more of the real defaults firmed up and shipped in a milestone.
The current suspicion is that the best candidate would be a webcal:
handler (as specified in http://www.whatwg.org/specs/web-apps/
current-work/#custom-handlers) which will fetch an ICS file and
render it to HTML. There are a sufficient number of webcal: links
scattered about the net that it seems likely that folks will
actually hit this in the course of using the alpha, and it should
be (we think) pretty easy to implement given existing (Perl | PHP |
Python | ...) library modules for ICS, calendars, HTTP, etc.
Another possibility would be to hack something like WebCalendar
<http://webcalendar.sourceforge.net/> to support the WhatWG API and
put up an instance of that.
Is anyone interested in helping make something like this come
together in pretty short order?
I think this can be done pretty simply. One idea I have is to create a
web service that builds an HTML page from the ICS data that will list
each event in the ICS file in a nice, easy to read fashion. We might
use something like the "event invitation" dialog from the Lightning
project  for inspiration.
Other thoughts? Does anyone have any feedback regarding various
advantages/disadvantages of ICS parsers in Perl, Python, or PHP?
Thanks for the help!
This seems like a fine plan to me.
> Other thoughts? Does anyone have any feedback regarding various
> advantages/disadvantages of ICS parsers in Perl, Python, or PHP?
Given that we're just looking for basic functionality testing, I'd
personally just go with whatever language/environment you're most
comfortable/productive with, as long as it has some sort of ICS parsing