WebDAV based Shar"> Thoughts about WebDAV based Sharing

• Examination of current implementation
  • Entire items are sent across the wire, even if a single attribute changed
  • A change to a large ref collection requires the entire list of references to be sent
  • Simultaneous writes aren't handled properly
  • No chance of merge conflict resolution
• An alternative server proposal
  • Server has a chandler repository, and isn't just a network filesystem
  • Change-logs are sent across the wire (we already do the work to produce these change-logs, so why not take advantage of them) instead of using WebDAV access
  • Take advantage of the merging capability of the repository, handling of multiple views, etc.
  • Be able to tie access control directly to our content model
  • Clients sync as follows:
    • For each shared ItemCollection^?, a client keeps track of what server it has been published to, the server's repo version number at the time of the last sync ("LastRemote"), and the local repo version number at the time of the last sync ("LastLocal")
    • When a sync is to be performed, the client asks the server "what has changed since your repo version "LastRemote" for this Item (Collection)"?
    • Server checks authentication/authorization and responds with a log of changes between version "LastRemote" and present version (filtered to only include log entries that correspond to items in that collection); included with the log is also the server's current repo version number.
    • Meanwhile, if the client has write privileges for this collection, the client is also asking the local repository "what have I changed since version "LastLocal" (filtered to only include log entries that correspond to items in that collection)
    • Those two logs can be compared for overlap. Overlap can be presented to the user to decide what to do (or there can be a policy such as server wins, or local wins)
    • Changes received from the server are applied locally; "LastRemote" is now set to that server's current repo version number
    • If the client has write privileges, the log of local changes for this collection are sent to the server; of course the server only accepts these changes with appropriate write privilege.
    • Because of repository views, those uploaded changes are atomic
    • If the upload is successful and committed, the client now updates the ItemCollection^?'s "LastLocal" to record the current local repo version number.
    • Sync complete
  • How does authentication work?
    • Having the participants' public keys inside the SharingStatus^? items would be ideal; solving the public key exchange would make so many other things easier :-)
  • How does authorization work?
    • Assuming authentication is accomplished, authorization for read or write access is done simply by looking at the SharingStatus^? items hanging off the ItemCollection^? (these are a set of items that connect an ItemCollection^? to people and privilege, as well as the status of invites and responses)
  • What if multiple clients are sending changes to the server simultaneously?
    • Since those changes are being handled within separate views, they're not stepping on each others toes until they commit
    • So the first client to commit in this case works as usual
    • Subsequent clients will go through the same merge conflict resolution as a local repository would. In fact, the server could respond to a client that his changes caused a conflict and could ask that client for resolution (or again, there could be policies set up such as "last write wins").
    • If client A and B were simultaneously publishing, A committed before B, and B resolved the conflict by overriding some of A's changes, by using the sync procedure outlined above, A would receive those changes the next time A synced.
  • What about WebDAV access for non Chandler clients?
    • If we really want that, it could be added as a layer above the repository at some point.
  • Benefits of using change-log based collection sharing:
    • Less network traffic
    • Atomic transactions
    • No locking required
    • Merge conflict resolution
    • Authorization is tied directly to a collection; no "accounts" need to be created. To bootstrap the process, out of the box a server's repository could have a "root" collection to which the server admin has write privilege. Into that root collection could be added collections which are the moral equivalent of a user's "home directory" and a user would have write privileges to add items (other ItemCollections^?) to that "home collection". Only users which are initiating a share would need to have one of these home collections to add their shared collection to -- the sharees would only need to have their authentication/authorization data stored in the SharingStatus^? items for each shared collection. Since the sharer can grant access to any sharee, this eliminates the "everyone needs to be on a single server" problem.
    • Code to compute change-logs (down to attribute-level detail) is already written and operational
  • Problems
    • ??

-- MorgenSagen - 04 Nov 2004