Sharing Network Architecture Thoughts and Requirements

June 10th meeting

• Mitch, Katie, Lisa & I met yesterday to make progress on this issue. Here're some personal notes from this meeting and other conversations
• We are renaming what I've called the "Sharing Transport" decision to the "Sharing Network Architecture" decision.
• We are going to make this decision based on requirements from 3 groups:
  1. Architectural/implementation issues
  2. Design requirements as mainly captured in CanogaSharingDesign20040419 and CommunicationsDesign
  3. Deployment and setup issues, including understanding infrastructure, supplied by OSAF and/or other parties, that need to be in place for Chandler users in the Canoga and Westwood timeframes, and how such infrastructure can impact the end-user.
• Lisa presented different options for implementation phases for sharing scenario #4 (sharing through WebDAV servers). I need to get more details to Lisa's plans, but Katie later clarified that it was loosely analogous to implementing "remote browsing" first and then "true sharing".
• I clarified with the group that Scenario #3 (sharing by proxying through messaging servers) could theoretically have just as high a chance of sharing success as Scenario #4 (sharing through WebDAV servers), as long as we relax the assumption that messaging servers have no store. XMPP servers do have a store, it's just that most existing public servers set low limits (e.g. some Jabber server instances have 500k message size restriction).
• IMHO, the biggest architectural difference between scenario #3 and #4 is that in scenario #4 there is a single repository "source of truth" for any given item or collection. This has the huge advantage of avoiding N conflicting versions of the same item and having to resolve and communicate such conflicts.
• The WebDAV approach also builds on a body of work that has been highly successful and scalable (i.e. the Web)
• Mitch felt that the above two reasons should tilt us strongly in favor of the WebDAV approach, and we should investigate the feasibility of the approach based on the above 3 groups of criteria.

Thoughts and requirements

WebDAV-approach issues I'm tracking categorized in the 3 groups:

Architecture

• Push vs. Pull When an item or collection is edited, are these changes pushed to the subscribers? Or do Chandler subscriber clients have to poll or pull for these changes? It became apparent in the meeting that Lisa was thinking of the pull model, while I had a push mental model. I believe data from a WebDAV server needs to be pulled (perhaps that is why Lisa has a pull model). So, if we want to adopt a push model, do we need some alternate notification system? OTOH, can we accept a pull model? What is acceptable in terms of items being out of sync?
  • MimiYin 12 Jun, 2004 As far as workflow goes, pull is probably okay. There just needs to be a way for Chandler to be able to distinguish between Shares that are pulled silently (lower-case "n" notifications) and Shares that ping the recipient with a capital "N" Notification once they've been pulled.
• Data Model Lisa and Katie brought up the issue that the richness interconnections of items and collections have to be phased in or the richness reduced when stored on a WebDAV repository (this phrasing needs work). I need to understand this issue and limitations better in terms of working with Lisa to sequence 0.4 features.
• Security and Privacy
  • Do central servers complicate certificate mgmt? how so?
  • what other security & privacy issues are there with this approach?
  • ChaoLam 14 Jun 2004: Conversation with Lisa suggests this is a big issue. Retrofiting certificate management with WebDAV servers will require a lot of work. Lisa suggests going back to username/passwords and perhaps tickets as an approach. Also usernames/passwords and extranet support was discussed. This also impacts whether we should have the ListOfPeopleYouShareWith feature.
  • MimiYin 14 Jun 2004: Realized after speaking with Chao that if there are multiple WebDAV servers out there, users could potentially end up managing multiple username / password accounts. In the web model, this isn't an insurmountable problem because websites are memorable locations (amazon.com v. buy.com v. wellsfargo.com). The metaphor is akin to having different keys for different houses. However, WebDav^? servers as destinations for sharing in and of themselves aren't particularly memorable and it will
    1. be difficult for users to remember multiple username / password combinations for "different", yet largely indistinguishable WebDAV server accounts
    2. mystify users why some sharing partners "live" at the same address and require the same username / password combination and others don't. The underlying architecture break's the simple user mental model options when it comes to username / password pairings: Is it per sharing partner? or per share. In the WebDAV model, it's neither, it's per WebDAV server.
  • That being said, if there some way we could control / influence the "account setup" wizard user experience, we could help the user along by creating the same username / password pair for all WebDAV accounts. This problem also goes away if we provide a "centralized" server for all Chandler users.

Design requirements

• I want to to work with Mimi to reimagine our sharing workflows with the WebDAV approach concretely in mind. How have things changed? What existing sharing issues may be resolved with this choice (e.g. resharing, conflict management)? What new issues may arise?
  • Can we reconcile Mimi's notions of shared item versions with WebDAV versioning?
• Mimi and Lisa have both suggested we may want to consider approaching item sharing and collection sharing differently. I want to explore this approach further
• Based on our target users and our identified use cases, what are the salient metrics to judge efficacy of our sharing network architecture? e.g. group size, expected responsiveness, transaction volume, transaction size, etc.
• sharing should be possible for clients behind firewalls

Deployment/Marketplace

• What are the ways a user can get access to a WebDAV account? In each way, how easy is it to set one up?
• How would users link up an existing WebDAV account with a Chandler client? e.g. do they have to match WebDAV directory to Chandler repository?
• Landscape of WebDAV servers. What do we need to investigate further:
  • Availability and support
  • Cost
  • ease of administration and maintenance (not just technical, but availability of resources to help out)
  • Reliability
  • Performance (throughput and latency)
  • Vendor commitment
• What are limitations of today's WebDAV servers?
  • ACL/Permissions?
  • What else?

Other points about WebDAV approach (needs to be filed somewhere):

• Seed for Higher Ed central server
• Possible basis for web-based Chandler
• support for clients behind firewalls (as long as WebDAV server is outside firewall)

-- ChaoLam - 11 Jun 2004