[Dev] The Chandler/Cosmo sharing format

[Brian Moseley]

On 3/3/06, Lisa Dusseault <lisa at osafoundation.org> 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">lisa at osafoundation.org</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.