[Dev] The Chandler/Cosmo sharing format

[Lisa Dusseault]

I don't disagree with any of this (and I thought Morgen wrote a great  
summary of the options and trade-offs).  We had our own  
standardization trade-offs to get to this point.  It's not too late  
to voice an opinion -- CalDAV is in WG last-call right now.

However, I don't exactly recommend inventing a new format just for  
use between Chandler and Cosmo.
  - Even though that would allow Chandler and Cosmo to do cool things  
together, those things aren't impossible when using iCalendar and XML  
files.
  - It would make Chandler/Cosmo interactions "more different" than  
those with other CalDAV servers, more different things to maintain,  
QA, and figure out how to solve problems in.
  - A new protocol or format is hard to design for extensibility and  
longevity, and then to maintain release to release with backward- 
compatibility.  We are already facing that for the XML files, why  
extend the problem when we actually want to fix the problem?

Lisa

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

>
> 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev