Sharing Format Meeting

Agenda

- Requirements for cosmo/chandler sharing format, cosmo/scooby sharing format (30 min) - (includes noting non-requirements)

- Proposals on the table (20 min)

- List of open issues/problems (20 min)

- Brainstorming/problem solving (50 min)

Requirements

Katie: high level proposal - Cosmo should support rich sharing (beyond calendar) for Chandler and Scooby. This includes stamping, items in multiple collections, bidirectional references

(The proposal was originally posted to the cosmo dev list)

A. Desktop Client <-> cosmo support "rich sharing"

B. Standard formats where sensible

C. Cosmo implements standard formats/protocols for interop with existing/future clients: CalDAV iCal+WebDAV Atom/RSS CardDAV^? Atom Pub/GData

E. Web client <-> cosmo supports "rich sharing"

F. Desktop client supports other protocols for interop

G. Web client supports other protocols for interop

H. Web client uses the same protocol as Desktop?

• br: as long as the protocol is rich enough - scooby wants fragments of information while Chandler usually wants all information. Web client and Desktop client have different access patterns.

Def: Rich sharing

• Extensible (ad-hoc attributes, new types/kinds)
• Beyond Calendar
• Bidirectional Refs
• Stamping
• Items in multiple collections
• Multiple collections shared together
• track who changed what

Relative priorities: Q: relative priorities of F, G vs C? A: F and G are long term priorities, but not a priority in the short term.

Overall priorities: #1: A and E #2: C, #3: B

What about backwards compatibility? (#2)

What about keeping the protocol/format open so that others can use it? (#2)

Additional requirements:

• (morgen) decouple sharing format from Chandler domain model
• (morgen) avoid multiple resources to represent an item (avoid consistency problems)
• (bcm) Miminize storage for a given shared item
• (capps) Performance
  • be able to tell what needs to be fetched
  • just send diffs
  • only send what's new (not duplicating info)
• (br) Don't require that what is sent over the wire is what gets stored.
• (towns) Allow conflict resolution to happen where it needs to, possibly at a higher level
• (morgen) Server side change notifications
• (capps) End user change notifications from server
• (bcm) Transactions? Some benefits to remaining stateless

Q: Are we assuming WebDAV?/CalDAV? A: No we are not.

Q: What about security and access control? Now it is nice that we can get a ticket on the whole collection. Unclear whether we need something more fine-grained than that. Do we need to integrate with external authentication/authorization systems?

• finer grained
• account based
• access to sets of collections not just single collections

Existing work (via Lisa)

• RFC for diffs in DAV
• rsync
• RFC(?) for WebDAV binding (symlink like functionality)
• MS WebDAV extension for multiple-request transactions
• CardDAV^? sync affordance
• SyncML

Proposals

Morgen: Today Chandler creates two "copies" of each calendar event. Problems with DAV: have to deal with complete resources, and need diffs Would like to present a UUID and just get the item/bag of attributes JCR has a mode that allows the UUID as key mode.

BCM: Cosmo should be able to be able to support arbitrary mixed content. The Desktop Client is using one of the many protocol buses into Chandler.

WebDAV as base protocol? CalDAV? Canonical XML format?

Formats:

• RDF XML + RDF Schema
• CloudXML
• Issue: pointers vs copies - multiple items (one in a each collection) or one item per resosurce

(bcm) Lets have two proposals, one DAV based, and one not and then let's compare/contrast

DAV Based

• diff based ACID syncing
• could use multi-get report in Cosmo 0.3, but you still get the complete info of things that changed; so would need to optimize by getting a diff; would allow read/write in a single transaction
• could collections themselves have an ETag? - we could do something custom here - PROPFIND is expensive - PROPFIND needs acceleration; collapsing the check for change and the retreival of changes seems like a good idea.
• imagine that we create a new custom REPORT that gives a sync changeset - a custom SYNCREPORT
• attribute level diffs not resource/item level diffs - for performance, potentially makes schema upgrade easier
• need whole history of changes since last sync or just the last change
• don't use timestamps, use a server generated version number - avoid clock skew problems
• present alternative namespaces? use accept header for those who will use it

Not-DAV Based

• Essentially Microformat approach (reuse native formats)

Open Issues

• Versioning
• ACLs
• End User feature: do we need granular/complete history of a series of changes to an item (think a history of all editors of an item/event)
• Scooby problem: update an event that is in two calendars, only one gets updated
• attribute level diffs / syncing
• priorities
• migration using sharing
• Proposed staging
  • investigate cosmo sync perf
  • SYNCREPORT
  • Chandler starts using new format
  • Cosmo undestands format (translations)
  • Cosmo implements transactions
  • Chandler can break out clouds
  • ?migration

-- TedLeung - 10 May 2006