I haven't responded to this thread in a few days since other things
have been coming up, but I wanted to fill people in on my current
thinking.
First a recap of the sharing format goals:
1) Decouple format from Chandler internal domain model
2) The format should be extensible to support new data types
3) Strive to use existing standards
4) Support stamping (an item can be of multiple types simultaneously)
5) Single resource per item
Proposal:
When Chandler shares a collection, a single Cosmo collection is
created (i.e., one-to-one mapping between collections), and for each
item in the Chandler collection, Chandler publishes an RDF/XML
resource into that Cosmo collection. Cosmo scans each resource for
any calendar-specific attributes (identifiable by XML namespace) and
stores those as properties on the resource in order to perform any
CalDAV-specific actions it needs to do, like serving iCalendar to
CalDAV clients. When a CalDAV client publishes an iCalendar
resource, Cosmo parses the iCalendar and modifies the RDF/XML
resource accordingly.
Chandler still gets to share any type of data, Cosmo only needs to
understand a subset of that data, there is one DAV resource per item,
and we get interoperability with other clients.
Rationale:
All the goals can be solved by having Chandler publish RDF/XML
resources which use 'well known' vocabularies, and we can add
vocabularies for data types that don't have a standard. There is a
spec for RDF/XML syntax:
http://www.w3.org/TR/rdf-syntax-grammar/
There are already RDF/XML vocabularies for various data types, so we
don't have to reinvent the wheel or develop specs for them:
Calendar: http://www.w3.org/TR/rdfcal/
Contacts: http://www.w3.org/TR/vcard-rdf
Mail: http://www.openhealth.org/xmtp/
From responses on the dev list and from talking to people, I think
most of us agree that having multiple files representing an atomic
entity is undesirable. I can tell you from experience that tracking
multiple resource bodies, URLs, and ETAGs for a single item is --
while possible of course -- complicated and a bit inelegant for my
taste. I certainly wouldn't expect the developer of some other
client who wants to interop with us to go through what Chandler
currently does. I don't want to explain to this developer, "For
these attributes read this resource body in this format, and for
other attributes read this other resource body in another format.
Oh, and make sure you remember to process the XML resources before
the ICS resources." And what happens when it's time to implement
CardDAV, add a third resource to the mix?
Further details:
There are some details to work out, including how clients and Cosmo
negotiate the content types being transferred. At first it seemed
like using the Accept: header would suffice, but Brian Mosely
recently found some arguments for why relying on that header can
cause confusion. Perhaps we use different URIs for each content
type; if a vanilla CalDAV client puts a resource named 'xyzzy.ics',
then Cosmo makes that item available to Chandler as 'xyzzy.xml'. Or
perhaps we use a query string to explicitly give type information.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
