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