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?
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
