Hi, Mikeal
Thanks for looking into this. I have a couple of comments inline, and
then some Chandler-specific observations at the end.
On Apr 10, 2006, at 8:03, Mikeal Rogers wrote:
In writing an emulation of Chandler 0.6.1 sharing in DAVTest for
cosmo automation I had to spend many hours inside an ethereal
capture of a Chandler TestSharing.py conversation.
I've committed the findings to a nicely formatted wiki page in the
hopes of starting a dialog as to why some of this is happening.
http://wiki.osafoundation.org/bin/view/Journal/
MikealRogers20060410Chandler061Cosmo03Conversation
Chandler is very very chatty, but the only issue that stands out to
me is the identical PROPFIND requests in sequences two and three.
Interesting. Do you see those two requests in your twisted.log (in
your Chandler profile directory)? I see only one when in mine when I
share from Chandler 0.6 -> cosmo 0.3.
Also, I'm wondering why Chandler is keeping all the TCP connections
open until 2 milliseconds after it has finished and then closes
them in a totally random order.
My twisted.log indicates that the server shut down the connection:
2006/04/11 10:50 PDT [WebDAVProtocol,client] [Disconnected]
[Failure instance: Traceback (failure with no frames):
twisted.internet.error.ConnectionLost: Connection to the other side
was lost in a non-clean fashion: Connection lost.
From Chandler's point of view, there are a couple of issues here:
1) Some of the hoops we leap through (OPTIONS + PROPFIND) are related
to try to determine whether resources exist on the server or not. In
general, we could cut out a lot of this stuff (which is error-prone
anyway) if we did something more like
MKCALENDAR /cosmo/home/mikeal/my%20calendar/
If-None-Match: *
MKCOL /cosmo/home/mikeal/my%20calendar/.chandler/
If-None-Match: *
assuming this is valid.
2) Chandler should be closing its TCP connections itself, so the
session doesn't hang around on the server unnecessarily. A question
for the HTTP experts: is there a recommended way of doing this? (In
IMAP, I'd send a LOGOUT command. Here, I could just close the socket,
or maybe send some request (er, which one?) with a Connection: close
header).
3) It would be nice if we used a single connection (a.k.a.
ServerHandle, but maybe HTTPClient) to handle both the CalDAV and
cloud xml shares. I'm not sure how much reworking of the existing
sharing code this would entail.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
