[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  

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.


More information about the chandler-dev mailing list