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

[Kervin L. Pierre]

Hello,

Is this format proposal tackling the CalDAV
client/server synchronization also?  Or is
it only dealing with representing further
resource information on the CalDAV server?

What does "share" versus "publish" mean?

Best regards,
Kervin

Katie Capps Parlante wrote:
> 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
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>