How Chandler Subscribes to a URL:

• It does a PROPFIND on the URL (using either a ticket, or basic auth if it can find a matching account) using this:

<?xml version='1.0' encoding='UTF-8'?>
<ns0:propfind xmlns:ns0="DAV:">
   <ns0:prop>
      <ns0:current-user-privilege-set />
      <ns1:ticketdiscovery xmlns:ns1="http://www.xythos.com/namespaces/StorageServer" />
      <ns0:getcontenttype />
      <ns0:resourcetype />
      <ns0:getetag />
      <ns0:displayname />
   </ns0:prop>
</ns0:propfind>

• If the collection turns out to be a CalDAV calendar, we do another PROPFIND of URL/.chandler to inspect the possible XML fork subcollection.

• If CalDAV or WebDAV we then do a PROPFIND (Depth: infinity) to get the list of resources:

<?xml version='1.0' encoding='UTF-8'?>
<ns0:propfind xmlns:ns0="DAV:">
   <ns0:prop>
      <ns0:getetag />
      <ns0:resourcetype />
      <ns0:displayname />
   </ns0:prop>
</ns0:propfind>

• Next, the soon-to-be-obsolete ManifestEngineMixin^? _get( ) method does an OPTIONS; if PROPFIND is allowed, then it does a PROPFIND, otherwise it does a HEAD

• Finally it does a GET on each resource

Notes

in 0.6, cosmo will have separate urls for webcal and dav:

* GET on the webcal url will get you a monolithic icalendar resource, but PROPFIND will get you a 405.

* GET on the dav url will get you a html directory listing (including alt links to the collection via webcal, ui, morse code, atom), and PROPFIND will get you a 207.

note that caldav provides a very specific mechanism to determine if a resource is a calendar collection: PROPFIND the url and look at the DAV:resourcetype property to see if it contains the element.

you can PROPFIND the collection for the ticket:ticketdiscovery property. if you're passing a ticket as the credential for the PROPFIND, the only ticketinfo that will be included in the ticketdiscovery property will be that of the ticket credential you provided.

calendar collections are not required to support subcollections.

caldav servers are required to support webdav acl, so a client could theoretically use that to determine permissions. if one or both of the participants don't support acl enough for this to happen, then i presume the client has to resort to a trick like the one you've used.

you might consider putting a dummy event resource into the calendar rather than creating a subcollection. of course, for this to work, the calendar collection must support events (which you can verify by checking the CALDAV:supported-calendar-component-set property).

So far as I know GET on the URL will cause a large download from Apple's server (as well as the current but soon-to-be-obsoleted Cosmo behaviour), and will also miss out on the CalDAV-ness of the collection. Maybe, to do a subscribe, Chandler should do a PROPFIND first, asking for at least:

- ACL (current-user-privilege-set) - getcontenttype - resourcetype

If that fails, we would revert to webcal mode (i.e. just GET the URL if it's text/calendar).

As a general question, how would we know when a dav URL supports eim+xml? Is there a separate DAV property (or added DAV:resourcetype) for that?

cosmo won't be implementing eimml over dav, just over morse code.

-- MorgenSagen - 08 Dec 2006