On 3/1/06, Morgen Sagen <[EMAIL PROTECTED]> 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. > 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. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
