[Dev] The Chandler/Cosmo sharing format

[Morgen Sagen]

On Mar 2, 2006, at 8:23 AM, Brian Moseley wrote:

> On 3/1/06, Morgen Sagen <morgen at osafoundation.org> wrote:
>
>> Now that I've typed this, I wonder if it really is worthwhile to use
>> 'standard' formats if we have to wrap them in this way.  No client
>> besides Chandler will understand this anyway.
>
> this is the heart of the matter, i think. icalendar and vcard are
> interop formats. they exist so that software from different vendors
> can talk to each other. we don't need to store our data in these
> formats - we just need to be able to deliver our data in these formats
> to software other than chandler and cosmo, and accept data in these
> formats from that other software.
>
> once we accept this premise, we are free to design a data format that
> is extensible enough to accomodate changes in chandler's repository
> schema, new content types, etc. as long as this format is well
> documented, cosmo can implement converters that export this format to
> icalendar for delivery to caldav and webcal clients and imports the
> format from icalendar from caldav clients. in the future, cosmo can
> implement similar converters for vcard+carddav and so forth.
>
> cosmo's only real requirement is that this data format expresses the
> same semantic information as icalendar (eg an event's uid, start date,
> end date, etc) so that these attributes can be indexed to service
> caldav reports.

Ok.  Although I've always been hoping for ACID transactions and the  
ability to send/receive 'sync diffs', if we decide we're going to  
stick with DAV, and the server can convert between a Chandler data  
format and the various standards, then that is a huge improvement  
over the 'dual-resource' sharing we do today.  I also have to  
apologize to Brian since he made this suggestion to me a day or two  
ago in an email which I completely missed until this morning.  So  
assuming we go this route, where on the Cosmo roadmap would this  
translation feature sit in terms of priority?  I hate to put Brian on  
the spot about this, but this would be seriously cool and helpful.  :-)


>
>> 5) If we go with CalDAV, I can't find a way around this problem.  I
>> thought maybe we could get by with sticking all non-CalendarEvent
>> attributes into DAV properties, but CalDAV doesn't let me PUT non-ics
>> resources in a calendar collection, so we'd only be able to share
>> CalendarEvents.  We could just do calendar sharing and that would
>> make things easier, but that's not very cool.  :-)
>
> i think this is one place where caldav has gotten it wrong. servers
> ought to be able to allow non-calendar resources in calendar
> collections if they so choose.
>
> caldav takes the prejudiced view (for reasons of compatibility with
> certain types of limited datastores) that the only content anybody
> will ever want to put in a calendar collection is calendar content,
> but clearly this breaks down when adding caldav support to a generic
> content repository.
>
> i have implemented "calendar collection" in cosmo as a mixin type. the
> primary type of a collection in cosmo is "dav collection" which can
> contain any arbitrary resource and on which we can set any arbitrary
> property. we can selectively add mixin types like "calendar
> collection" and "contact collection" to the collection as desired. the
> presence of these mixin types will cause cosmo to behave appropriately
> when caldav or carddav is used to access the collection.
>
> if we ignore the caldav restriction that we can't put non-calendar
> resources into a calendar collection, hoping that lisa etc will remove
> it from the draft ;), then chandler can create these "anything-goes"
> collections and stuff whatever data it wants into them, and when a
> caldav or carddav client comes along and interacts with one of them,
> the collection will behave exactly as that client expects.

+1, (+2 even)