[Cosmo-dev] chandler/cosmo sharing format -- requirements proposal

[Katie Capps Parlante]

In March, Morgen opened up a discussion about the sharing format the 
Chandler desktop client uses when publishing items to Cosmo. He outlined 
a number of problems and proposed some goals for the sharing format: 
extensible, stable, stop publishing multiple resources for a single 
item, etc.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-March/005309.html

After some discussion with Brian, Lisa and Bobby, Morgen made a proposal 
(publish RDF/XML resources to Cosmo collections):
http://lists.osafoundation.org/pipermail/chandler-dev/2006-March/005453.html

The conversation took a hiatus while Morgen went off to work on 
background sync. Jumping back into that conversation (and moving the 
conversation to the cosmo list), I wanted to throw out a proposal for 
how we might frame the requirements for the sharing format, looking at 
all three projects: the sharing server (cosmo), the desktop client, and 
the web client (scooby). This proposal is a synthesis of conversations 
with John, Morgen, Ted, Grant, Sheila as well as points made by Brian, 
Bobby and Lisa in the list discussions.

(Side note: I'm tripping over myself with project names here -- trying 
to make the point that all 3 osaf projects should embody what the design 
team has thought of as "chandlerness" -- flexible data model, rich 
integration between calendar/tasks/contacts/other in part inspired by 
GTD, etc. etc. Also, I'm sending this to the cosmo list only to avoid 
cross posting -- I believe interested parties from the other projects 
are on this list.)

Proposal
========

Sharing service big picture
---------------------------
The high level priority for the "chandler sharing service" should be to 
support "rich data format" sharing services. This includes both calendar 
data as well as more general forms of personal information (tasks, 
contacts, photos, etc.). It also includes data model features used by 
the desktop client (and eventually web client) like stamping and items 
in multiple collections. We want to be able to inter-operate with other 
clients, servers, and services (both to gain adoption and because this 
is the kind of world we want to live in) and we want to promote the use 
of standards to encourage inter-operation. We also want to use standard 
protocols to build on work others have already done.

Outline of requirements
-----------------------
A. The desktop client communicates with the sharing server using a 
protocol/format that supports a "rich sharing format"
    - reasonable performance characteristics
    - extensible format to support new data types
    - supports data model features: stamping, items in multiple 
collections, bidirectional references

B. The desktop client and sharing server use standard protocols and data 
formats where possible/sensible (avoid reinventing the wheel). Options 
include:
    - tweak CalDAV
    - build on DAV (RDF format as morgen proposed, or another format)
    - HTTP, Atom, some other solution?

C. The sharing server implements a variety of protocols to facilitate 
inter-operation with other clients
    - CalDAV
    - iCal style WebDAV + ics files
    - WebDAV + other standard formats (vcard, etc.)
    - Atom
    - RSS

E. The web client supports the same "rich data model"
    - stamping
    - items in multiple collections
    - bidirectional refs
    - extensible to support new types

F. The desktop client implements other protocols to allow it to 
inter-operate with other servers
    - CalDAV, iCal style WebDAV + ics
    - functionality may be less rich
    - the desktop client can speak to other servers using these 
protocols, but doesn't necessarily speak to Cosmo this way, and Cosmo 
handles interop with other clients

G. The web client communicates with the sharing service using the same 
"rich data format" protocol as the desktop client

H. The web client implements other protocols to allow it to 
inter-operate with other servers
    - CalDAV
    - iCal style WebDAV + ics

Priorities for the short term
-----------------------------
A and E are the top, driving priorities -- fully support the features of 
the web client and desktop client, in an efficient manner.

B is important for getting where we want to go in the short term, as 
well as not shooting ourselves in the foot over the long term. As Lisa 
points out, inventing a new protocol is difficult and costly. That said, 
the protocol/data format needs to support our requirements.

C is also important in the short term, prioritized to support 
inter-operating with clients with existing users (iCal, google?, etc.). 
We prioritize based on what we think will drive adoption.

F we freeze in the short term, with possible exceptions for critical 
bugs found against popular servers. The assumption is that interop with 
other servers is not high priority in the short term as it will not 
drive adoption in the short term.

H is low priority in the short term, but we get the architecture right 
such that we can do it in the longer term.

G is important in the near term to get the architecture right, perhaps 
staged along with web client functionality showing up.

Open issues
-----------
- Most notably, define the data format crisply. Perhaps start with the 
requirements -- anything missing beyond what is listed above?

- Can we do this by tweaking CalDAV, using options that Lisa suggested? 
Do we go with something that looks more like Morgen's RDF proposal?

- How is free/busy handled if we go with Morgen's proposal?

Thoughts?

Cheers,
Katie