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
On May 16, 2007, at 2:23 PM, Jared Rhine wrote:
What follows is an inquiry about the advisability and effort of
using HTTP "OPTIONS" instead of "PROPFIND" for Chandler to
determine if a given URL is a DAV URL. The inquiry is primarily
directed to Morgen.
I've spent a couple days looking at the server-side of a real-
world Morse Code driven service looks like. The standard pattern
for a synchronization is a 4-transaction HTTP set:
71.202.115.113 - - [16/May/2007:13:45:17 -0700] "PROPFIND /pim/
collection/723886a6-705d-11db-8ee8-99b22f7fce88?ticket=1zaf4xxac0
HTTP/1.1" 501 1238 "-" "Chandler/0.7.dev-r14332 (Linux; U; i386;
en_US)"
71.202.115.113 - - [16/May/2007:13:45:17 -0700] "HEAD /pim/
collection/723886a6-705d-11db-8ee8-99b22f7fce88?ticket=1zaf4xxac0
HTTP/1.1" 200 - "-" "Chandler/0.7.dev-r14332 (Linux; U; i386; en_US)"
71.202.115.113 - - [16/May/2007:13:45:17 -0700] "GET /pim/
collection/723886a6-705d-11db-8ee8-99b22f7fce88?ticket=1zaf4xxac0
HTTP/1.1" 200 5533 "-" "Chandler/0.7.dev-r14332 (Linux; U; i386;
en_US)"
71.202.115.113 - - [16/May/2007:13:45:17 -0700] "GET /mc/
collection/723886a6-705d-11db-8ee8-99b22f7fce88 HTTP/1.1" 200
1243606 "-" "Chandler/0.7.dev-r14332 (Linux; U; i386; en_US)"
So, it's a PROPFIND + HEAD + GET /pim + GET /mc.
The initial PROPFIND operation helps Chandler determine if it's
working with a DAV-based URL.
Essentially every Chandler-driven PROPFIND against the server will
fail. This is per the design.
However, it tweaks a little muscle in my sysadmin head: looking
for 5xx errors in an access log is one of the primary ways to tell
if something is breaking on the server. You better pay attention
if that metric suddenly spikes.
So I've a mild aversion to a regular, everyday operation
generating what looks like an exception condition.
All Chandler is trying to do is figure out if the URL is a DAV
URL. There's already a standard WebDAV mechanism to determine
this; it's the HTTP OPTIONS method.
I hesitate to even ask the question as what we have now works, and
it'd be a Morgen task, and Morgen is quite the busy camper these
days. But the question is out there now, and I'm guessing I'll
get a pretty reasonable answer that a good balance of these concerns.
Thoughts?
-- Jared
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
