Motivation

Since accepting a grant to develop a higher-ed version of Chandler, OSAF has always intended to create a central server product to complement the Chandler client. The central server product is necessary to meet higher-ed IT requirements such as high-availability, central management and nomadic access.

With our decision to use WebDAV as a primary component of our sharing network architecture, we have decided to accelerate our server product plan. This document describes our current thinking on how we plan to phase and develop this product.

Methodology

• I first outline a set of criteria for deciding how to phase this product. We should discuss if this is the right set of criteria and what is missing.
• To validate the above criteria and get a better sense of the different phases, I then list a set of workflows and features for the eventual server product we'll like to have. As each feature is fairly high-level, the feature may need to be broken down further and more detail may be required. I'll like input as to where this is necessary and a plan to get there.
• In the following in square brackets, I give my guess of where the phases fall (where work for the feature should begin), a '+' indicates an advance feature for that phase. It may take more than one phase to complete the feature, and it'll be helpful if we can break such features down so that fit cleanly within each phase.

Server Product Phases

Because the server product is complex with many requirements, we need to phase the product. Following are the key criteria/principles to decide what goes in which phase:

• Target user group phases: Canoga for small work groups, Westwood for higher education, first faculty, then adding staff and then later students
• Server scale: no of users in a work group, total users one server can support, total number of transactions
• Do we allowing collection sharing with users without accounts for the server hosting the share?
• The fewer product SKUs we have the better. Ideally we always have only one server product

[For discussion] Do the following product phases make sense?

• [Kibble] Initial phase, using an out-of-the-box open source WebDAV server such as ModDAV, requiring sysadmin assistance for account setup.
• [Hosted] OSAF WebDAV hosting to the public for individuals and small workgroups. See WebDAVHostingProject
• [Westwood] Stand-alone server produt for external use
  • Campus staff (hundreds)
  • Faculty & staff (thousands)
  • Campus wide (ten thousands and above)

Key server workflows

• User
  • Register for an account (Chandler and/or web interface) [Hosted]
  • Share a collection [Kibble]
  • Edit and change a collection [Kibble]
  • Modify a collection's permissions [Hosted]
  • Share with non server account users (e.g. through extranet accounts or tickets) [?]
  • Kiosk mode access (i.e. client has no repository) to Chandler server repository [Westwood]
  • Synchronizing user's Chandler repository from multiple machines to support nomadic access [Westwood+]
  • Collaborative calendaring functionality (not the focus of this doc and will be described separately)
• Administrator
  • Create and manage accounts [Westwood]
  • Create and manage policies and apply them to account groups [Westwood]
  • Warn and purge inactive users [Hosted]
  • Disk quota and bandwidth metering and enforcement [Hosted]
  • Server usage reports [Hosted]
  • Back-up and restore [Hosted]
  • Server cluster management (for fault-tolerance and scalability) [Hosted+]
  • Admin automation functions (e.g. deal with forgotten passwords) [Hosted+]

Key Features

• Security
  • Basic authentication [Kibble+]
  • SASL Authentication to own account [Westwood+]
  • TLS encryption for data transmission [Kibble+]
  • Share with other Chandler users who do not have accounts on owner's server (e.g. extranet accounts or tickets) [?]
  • ACL support at collection and item level, set from client and server [Hosted]
  • Forgotten password/username support [Hosted+]
• What do users store?
  • shared collections [Kibble]
  • entire repository (to support nomadic access including kiosk mode) [Westwood]
• Replication
  • Replication and synchronization of entire user repository against multiple clients [Westwood+]
• Reliability [Hosted+]
  • Architecture support for fault-tolerance and failover
  • Support for hot-swapping servers
• Throughput
  • Scale linearly as new servers are added [Hosted+]
  • Need more concrete metrics here
• Account management
  • Allow users to sign up and create own accounts [Hosted]
  • Administrators can create accounts in batches and assign account types (e.g. admin, student, faculty) [Westwood]
  • Meter and enforce bandwidth and storage limits to accounts [Hosted]
• Administration functions
  • Admin client [Westwood]
    • Create and manage accounts
    • Dashboard view of server issues
    • Edit and enforce policies in a scalable fashion (e.g. kiosks never store passwords, 10 MB quota for students)
  • Integrate with standard back-up software, support live back-ups [Hosted+]
  • Event logging [Hosted]
• Calendaring functionality is not the focus of this doc and will be described separately
• Other higher-ed requirements not captured here?

Questions

Design

• Will user data need to be encrypted for privacy reasons? [encrypting shared data is much harder]

Engineering/Architecture

• Will conflict resolution always be done at the client side? [Main.JuergenBotz: Server needs to provide some information about item versions, but as much as possible, client should do most of the work]
• Will the server communicate directly to other servers? e.g.
  • • IMAP/POP
    • LDAP including certificate authorities
    • Kerberos
    • Calendaring server is assumed to be part of this product?
  • JuergenBotz: Preferably not initially. Leave it to the client to communicate with other servers
• JuergenBotz: If servers are being replicated on-the-fly, back-up features are not necessary (replication is cheaper and better)

Next steps [for discussion]

• Agree on server product phases and rationalize phases with Chandler timeline
• Match above features to server product phases
• Define server product milestones for 0.5
• Do we need a new server product working group?

See Also

• WebDAVHostingProject
• LisaDusseault20040813

-- ChaoLam - 30 Jul 2004

---

Comments

One thing Stuart & I have learned is that for good synchronization of properties, WebDAV servers need extra features. Right now the server has no reliable way of telling clients when the resource properties have changed. Clients can either expensively maintain a property change log on the server, or download all properties every time a synch is done. This is a lot of work.

• LisaDusseault - 11 Oct 2004

I would like to bring up an alternative proposal which doesn't involve WebDAV. I think by using a smart server based on top of the Chandler repository, we can leverage a bunch of work that Andi has already done, and sync more efficiently. Please see my notes at MorgenSagen20041103