[Chandler-dev] Re: [Cosmo-dev] Detailed account of Chandler <-> Cosmo sharing conversation

Grant Baillie grant at osafoundation.org
Tue Apr 11 11:31:07 PDT 2006


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



More information about the chandler-dev mailing list