On Jun 26, 2007, at 9:57 AM, Grant Baillie wrote:
On 26 Jun, 2007, at 09:51, Morgen Sagen wrote:
I was thinking about this yesterday and it's possible that I could
simply have Chandler start off with a GET of the URL. Then,
looking at the Content-Type header in the response, I could do the
following:
"application/eim+xml" -- hand the response body to the morsecode
subscription code.
"text/html" -- parse the response body for a morsecode URL; if
there is one embedded, GET the morsecode URL, passing new response
body to morsecode; otherwise this could either be a regular web
page or it could be a DAV collection, so I could then OPTIONS and
look for a DAV header.
"text/calendar" -- hand the response body to the monolithic
icalendar file parser
Storing the response from the initial GET and passing it to the
code that will eventually process it (rather than having that code
go and fetch it itself as it does today) will take a little bit of
work, but should be possible.
How does this sound?
Hmm... I think this would be wrong in the case of CalDAV
collections that return text/calendar for a GET of their collection
URL: You'd end up with a read-only .ics-style subscription instead
of a CalDAV subscription.
I know cosmo used to be one such server, I'm not sure if other
CalDAV servers do it (Apple's might well, to support older versions
of iCal.app).
--Grant
Right, Cosmo no longer does this, and I suppose I could do an OPTIONS
following the GET of a text/calendar to see if it's a DAV server
after all.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
