On 25 Jul, 2006, at 12:00, Heikki Toivonen wrote:
Grant Baillie wrote:
FWIW, I figured out 2 more, because the Sharing code makes separate
connections to determine what your server supports (in
Sharing.publish()), and to find a unique collection name to share to
(Sharing.getExistingResources()).
Could we cache the server capabilities?
Could we try to publish to some name with the condition that it will
fail if that name already exists, and retry with different name if so?
Sure (in fact, the second suggestion is in general more robust
anyway); but either way we should just use a single connection.
I also found what I think is the last wasteage of connections:
There's a connect() API on SharingConduit that's called near the
start of publishing a share; the current implementation of CalDAV/
WebDaVConduit throws out the old connection (without closing it) and
creates a new one.
FWIW, I'm not seeing the 2 minute connection delay Lisa saw (even
publishing the same calendar -- Generated3000.ics -- to cosmo-dev). I
hope it wasn't an artifact of using an old checkout of Chandler.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
