On 3/3/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: > 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.
consider the opinion voiced earlier in this thread :) > 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? what's the alternative? 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? 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? <cosmo:item primarytype="cosmo:event" mixintypes="cosmo:contact, cosmo:msg"> <cosmo:attr cosmo:name="summary" cosmo:created="xxx" cosmo:modified="xxx" cosmo:who="bcm">this is an item</cosmo:attr> <cosmo:attr cosmo:name="firstname" cosmo:created="xxx" cosmo:modified="xxx" cosmo:who="bcm">brian</cosmo:attr> <cosmo:attr cosmo:name="to" cosmo:created="xxx" cosmo:modified="xxx" cosmo:who="ticket-cafebebedeadbeef">[EMAIL PROTECTED]</cosmo:attr> </cosmo:item> this would not make life difficult for cosmo. when processing a caldav or atom request, it could easily convert this to icalendar or hcalendar. when accepting an event from a caldav or atom client, cosmo could convert the icalendar or hcalendar into this format for indexing and storage. supporting a format like this would make cosmo very appealing for clients other than chandler as well. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
