[Dev] The Chandler/Cosmo sharing format

Lisa Dusseault lisa at osafoundation.org
Mon Mar 6 16:21:35 PST 2006

On sharing 1 item == 1 WebDAV resource:

On Mar 5, 2006, at 8:58 AM, Brian Moseley wrote:
> it seems to me that morgen's trying to figure out:
> 1) how to avoid storing multiple webdav resources for a single  
> shared item
> 2) a sharing format that can fully express all of chandler's
> information about a calendar item, even things that might not be
> directly expressable by icalendar
> 3) a sharing format that can cope with stamped items
> #1 could be as simple as: use icalendar for calendar items, vcards for
> contacts, and "something else" for everything else.
> #2 could be solved for icalendar and vcard with x-properties.
> but what about #3? are x-properties sufficient for this purpose? what
> about an item that's both an event and a contact - do we store it in
> icalendar or vcard? what about an item that's an event, a contact, and
> an email message with a big binary attachment - do we store it in
> icalendar, vcard, or mime?

If we were sharing email and tasks as well as events to a CalDAV-only  
server, then yes, all the stamped information besides the event  
information could be stuffed into x-properties and/or attachments.   
But actually, the problem comes when a server is capable of  
understanding events as one kind of resource, tasks as another kind  
of resource, and possibly in the longer run email as a third kind of  
resource.  If we had a general server capable of understanding those  
different types, we wouldn't want to make one type "dominant" (the  
event) and hide the information for the other kind in extension  

It may be that stamped items are the one thing we have to share as 2  
separate resources to maximize interoperability. E.g. for an Event 
+Task we would have

   http://share.o11n.org/users/lisa/work/staff-meeting-event -- this  
resource has the VEVENT properties and a pointer to the other
-- this resource has the VTODO properties and a pointer to the other

Another client could reasonably understand both the event and the  
task and even possibly understand that they were tied together. They  
would be displayed separately in most clients, at least for the  
medium term, but they'd both display.

I understand that doing a PUT for both these parts of the stamped  
resource is non-atomic. But there may be other ways of solving that  

1.   Microsoft invented a WebDAV extension to combine multiple  
requests in a transaction:
	LOCK with special syntax to start transaction and get transaction ID
	PUT #1 with Transaction header to do the first resource created in  
the transaction
	PUT #2 with same Transaction header
	UNLOCK with transaction ID to commit the changes

2.  The "If" header allows you to create two resources in a way that  
creating the second one relies on the existence of the first one.   
The second PUT would look like this

	PUT /users/lisa/work/task-prepare-staff-meeting HTTP/1.1
	If: <http://share.o11n.org/users/lisa/work/staff-meeting-event>  
	Content-Type: text/calendar

There's two options, there may be others.

> in the chandler repository, an item is basically just a list of types
> and a flat list of name/value pair style attributes, right? couldn't a
> very simple xml format address that in a flexible way?
> ...
> supporting a format like this would make cosmo very appealing for
> clients other than chandler as well.

Yes, but maintaining such formats across releases and as requirements  
change turns out to be very painful.  Internally both Cosmo and  
Chandler maintain their own representations, but externalizing either  
one of those is something that's even more difficult to maintain than  
an interoperable standard format.  We want version 0.7 of chandler to  
interoperate with people running 0.8 and so on.  Which version of  
Chandler becomes the one whose internal format becomes externalized  
and set in stone, and why that version?


More information about the Dev mailing list