Sharing protocol implementation options

1. WebDAV central server

• 
• WebDAV server acts as the point of coordination all changes and conflicts (e.g. through locks)
• Change notifications can be pushed through separate means (e.g. XMPP as below)
• Individual clients pull in changes to update own repository and push its changes to the server
• Strengths:
  • Very scalable to large groups
  • Central server approach can be basis of Westwood central server plans
  • In-house expertise, few anticipated technical issues
  • Highest availability
  • Fewest synchronization problems
  • Basis for web publishing and other forms of interoperability
• Issues
  • Barrier to entry of setting up a server account
  • Obtainability of server account
  • Ongoing of maintenance of server possibly an issue (alternatively: challenge to make server near-maintenance-free)
  • Restrictions on server storage space or bandwidth if externally hosted
  • Requires WebDAV extensions and modification to support outside server accounts
  • Requires OSAF to commit resources to build new product
  • Moving away from original P2P vision and obligation (e.g. requires central server, one real "owner" of data". Owner of data cannot be simply removed from ACL)
• Next steps
  • Explore plan to host OSAF WebDAV server
  • Explore plan to create server product (second Chandler product ahead of Westwood)

2. Proxied P2P by Pulling data and pushing change notifications (aka Hub and Spoke model)

• 
• Push / Store and Forward notifications of changes
• Pull changes
• Similar to WebDAV model, except WebDAV server is built into client itself, not a separate server
• Designate initial sharer the point of coordination
• Strengths:
  • Simple to set up and mantain
  • In-house expertise, few anticipated technical issues
  • Few synchronization problems
  • Basis for web publishing and other forms of interoperability
  • Just one product
• Issues
  • Availability of sharing depends heavily on avaibility of owner client being online
  • Not scalable beyond 30-person workgroup
  • Dilutes some P2P elements (e.g. one real "owner" of data". Owner cannot be simply removed from ACL)
• Next steps:
  • Discuss if item conversations can mitigate availability issues for key workflows
  • Basis for "dog food" candidate

3 Proxied P2P with Push

• 
• Current editing client responsible for pushing out and coordinating changes.
• Changes are pushed through store and forward XMPP server to shared clients
• No one client "owns" the data
• Manually activated Pull to synchronize
• Always receive changes before pushing out your own
• Strengths:
  • Simple to set up and mantain
  • Higher availability
  • Just one product
  • Closest to P2P vision
• Issues
  • Not scalable beyond 30-person workgroup
  • Restrictions on server storage space or bandwidth if externally hosted
  • N-way synchronization potentially very hairy
  • Non-guaranteed delivery of push messages could result in errors esp. conflict resolution
  • Healing network splits could result in errors esp. conflict resolution
  • Data pushing is inherently technically more dififcult (?)
  • Lack of P2P expert
• Next steps:
  • Discuss how crucial are conflict resolutions and how well we need to resolve them? (see below for discussion)
  • Discuss if item conversations can mitigate availability issues for key workflows
  • Get a P2P expert to appraise if our PIM workflows can mitigate the n-way sync issues to a manageable level

Network architecture #2 and #3 (Proxied P2P) both involve using messaging central servers (probably XMPP servers) to traverse firewalls:


For Network architecture #1, we assume WebDAV server to be outside any firewalls.

Factors for evaluation

• Barrier to entry of setting up and mantaining a server account
• Availibility
• Scalability
• In-house expertise
• Restrictions on server storage space
• Non-guaranteed message delivery
• N-way synch
• "P2P" vision and obligation
• Work required both on technical and product management side

Decisions made (28 Jun 2004):

1. We will go with Option#1 for sharing collections. After we implement an early version of option#1, we will decide if we still need to support option#2. This is the only form of sharing we will implement in 0.4.
2. We will support option#3 for sharing of single items only. This will be done to support the 1-time send update feature. We will use email as the messaging server to support option#3. This is a post 0.4 feature.