This gets Chandler to be interoperable with other calendar clients, but
only if Cosmo is used. It doesn't get Chandler to be interoperable with
Hula, Oracle server or other CalDAV servers, or is that still going to
work as it does today?
Perhaps we have different assumptions about the interoperability
requirements, there's been some talk about making that more explicit.
lisa
On Mon, 13 Mar 2006 14:00:49 -0800, Morgen Sagen
<[EMAIL PROTECTED]> wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
