Notes

Notes on Why Sharing is hard

Red indicates areas for further examination/action

• Today we use WebDAV, one resource per item

• Today's code needs to be special cased because of inconsistencies in the repository API's, in particular the streaming API for LOB's.

• We rely on the repository to take care of hooking up the reverse direction of a bidirectional ref when importing items from WebDAV
  • There's an issue with bi-directional references if you are not a Chandler client, but just a plain old WebDAV client

• Another difficulty with sharing is that the Chandler data model is inherently graph structured and WebDAV is tree structured. So we have the usual problem of flattening a graph into a structure that isn't really designed for it. The big deal here is avoid doing work the 2nd, nth(?) time we see the same Item in the graph while doing the flattening. This shouldn't be a surprise. There are also interesting access control issues because of the graph model.

• There are a bunch of issues in today's implementation related to ItemCollections^? -- is the rule re-run on the other side. Is the need to re-run the query causing perf problems (not yet).
  • Syncing happens manually -- the code must walk the repository attempting to discover whether items are dirty or not - it seems like this code should be taking advantage of notification to help precompute the set of items which are out of date. Today it's all polling.
  • John suggests we view a shared collection as sharing a cache of the query result set -- the extent of the query.
  • It's problematic that there are some items of itemcollection which really should not be shared -- is this another application of clouds
  • The fact that we are stuffing all the information up to the WebDAV server means that we can't use copy on demand (from the sharer) optimizations

• Sharing uses item attributes which causes items to become dirty when they really aren't (at least for sharing)
  • Would like a way to say that certain attributes don't count for sharing dirtiness
  • today this is done by inserting code into mapHistory, which ends up being inefficient. The need is to support change notification at the "this attribute of this item" level. The new monitors may facilitate some of this.
  • this is going to have the effect of making commit slower
  • another way to speed up mapHistory is to do some work in the background

• Clouds
  • The current cloud mechanism makes the initial export of shared items easy. Import is done by reference tracing from item collection items
  • Currently clouds don't specify literal attributes -- do we need a mechanism for specifying the literal attributes included in a cloud?

• Today syncing must go to the server and ask for any items that have changed. This means searching for all changed items using WebDAV, which is slow. We need some kind of aggregate record that indicates the set of items that have changed.
  • This is an interop problem because non-Chandler clients will make changes and will not update the record. Unfortunately, search all WebDAV resources is likely to be an unscalable solution.

• Q: changes needed for CalDAV
  • large - not necessarily hard, but not a lot of code reuse. Unclear to me how this will interact with ItemCollections^?

• Futures
  • WebDAV based repository backend
  • Instead of sharing individual items, share an aggregate item. Fewer (possibly) roundtrips in exchange for larger payloads.

-- TedLeung - 14 Oct 2004