Goal:

The goal is to allow the greatest amount of other-client-compatibility while reducing the number of locations Chandler needs to publish to (thereby reducing the number of URLs a Chandler user needs to juggle). The Chandler user should not need to think about choosing to publish their events one way and non-events a different way.

Terminology:

• "ItemCollection" == a Chandler collection of Items
• "collection" == WebDAV collection

Assumptions:

• The prime use case is Chandler sharing collections via Cosmo.
• If the user publishes a collection to a non-Cosmo server, functionality might be reduced. For example, if publishing to a vanilla CalDAV server, all non-Event items would be skipped. (Apparently we can put non-.ics resources into a calendar collection after all). And if publishing to a vanilla WebDAV server, other non-Chandler clients can't particpate unless they grok our xml. Chandler can still publish or subscribe to a monolithic .ics file however, since we do that today.
• Cosmo speaks WebDAV.
• Cosmo speaks CalDAV.
• A collection on Cosmo can act as both a WebDAV collection and a CalDAV collection simutaneously.
• There is a one-to-one relationship between a Chandler ItemCollection^? and a WebDAV collection. This means Chandler doesn't have to publish events in one CalDAV collection and non-events in another (WebDAV) collection.

Chandler publishing an ItemCollection^? to a server means:

• Chandler determines whether MKCALENDAR and MKTICKET are supported on the server
• If MKCALENDAR supported, Chandler uses MKCALENDAR to create the collection, else MKCOL
• PROPPATCH just after the MKCALENDAR to set DAV:displayname
• Chandler uses MKCOL to make a subcollection (named ".chandler"?) for storing our .xml resources
• If MKTICKET supported, Chandler requests two tickets: one for ReadOnly^? and one for ReadWrite^? access to the collection
• For each item in the ItemCollection^?:
  • Chandler PUTs a .xml file representing that item into the .chandler subcollection (CloudXML format)
  • If that item is stamped as an Event or Task, Chandler PUTs a VEVENT or VTODO .ics file in the calendar collection
  • Chandler records the ETAG(s) of the resource(s) for later comparison.
• Chandler records the local repository version number for later comparison.

Chandler syncing changes to the ItemCollection^? means:

• Chandler does a PROPFIND on the collection to determine the list of resources on the server, including their ETAGs
• For each resource on the server that is new/updated:
  • Chandler GETs the resource and hands the resource body to the importProcess( ) method of the appropriate Format class (either CloudXML or iCalendar) which either creates or updates an item locally
  • Chandler records the ETAG of the resource for later comparison.
• For each resource that used to live on the server but has disappeared:
  • Chandler removes the item from the local ItemCollection^?
• For each item in the ItemCollection^? that has changed locally since the last time I synced:
  • Chandler PUTs a .xml file representing that item into the collection (CloudXML format)
  • If that item is stamped as an Event or Task, Chandler PUTs a VEVENT or VTODO .ics file
• For each item that has been removed from the local ItemCollection^?:
  • Chandler DELETEs the corresponding resource(s) on the server

Non-Chandler clients interact as follows:

A CalDAV client can read and write to a Chandler-published collection (modifying only the .ics files). Question, are non-Chandler clients even aware that the .xml files exist? Possibly placed into a subdirectory if needed? Answer: it sounds like folks agree the .xml resources should be inside a subcollection.

A monolithic .ics file reader-or-writer like Apple iCal can ask for the same URL and get back a monolithic file (created by Cosmo). Hmm, what about the other way around? If iCal tries to write a monolithic ics file to Cosmo what happens? bcm responded: 'cosmo will decompose it into the constituent parts, create a calendar collection, and create resources for each calendar object contained within the ics file.'

Possible layout of resources on Cosmo (assuming I need to hide Chandler-specific XML from CalDAV clients):

~morgen/
   /Foo_Collection/
      /30495872340958234.ics
      /39487503948539458.ics
      /25923492387492373.ics
      /.chandler/
         /share.xml
         /30495872340958234.xml
         /39487503948539458.xml
         /25923492387492373.xml
         /23948729384792398.xml

Note that there can be more .xml files than .ics files since not all items in the ItemCollection^? will be stamped as Events.