Notes for server planning, sharing, etc -- strawman

Dogfood plan (0.4, 0.5 etc)

Minimum Functionality

For dogfood, Chandler must be able to publish any Item Collection, synchronize collections, and attempt to collaborate on authoring and managing items in a standard schema. Chandler must also be able to send and receive sharing invitations. Sharing single items is a dogfood goal but not a 0.4 goal.

Synchronization

Our 0.4 Synchronization model (which Sheila will be documenting in more detail shortly) will be mostly good enough for dogfood. The client remembers the server's ETag for each downloaded item, and can tell later if the item needs to be downloaded again or not. The client also remembers which items have changed locally, either online or offline, and attempts to upload to the server if the server's copy hasn't changed.

If the server's copy has changed, and so has the local copy, the client will attempt to automatically merge the two copies. The client will need to know what the item looked like before either the server or the local changes (this could either be by storing the previous version locally, or on the server in some way). That allows the client to see if the local changes are to different attributes than the server changes. If that's the case, the client ought to be able to automatically merge the changes made on each end. Note however, that this merging will not take into account the semantics of the item. For example, if an item had a "duration" and a "start-time" and "end-time" attribute, which needed to be kept consistent, this merge approach would not maintain consistency automatically. That ought to be OK for dogfood, as we learn more about what attribute consistency requirements we might have (there seem to be few at this point).

The client does not need to attempt locking at this point -- events are of small-enough granularity that we don't think we'll frequently run into simultaneous editing situations. Locking is probably a post-dogfood feature.

All of this requires a WebDAV server that supports strong ETags. We're also assuming that the server changes the ETag when only properties of the resource have changed. This is a bad assumption for the long run, because a server might change the ETag when the body changes (required) but leave the ETag unchanged when a property changes (unspecified). Relying on the ETag to change with property changes happens to work on Sharemation currently.

Our 0.4 synch model does not require the server to support locks.

Bindings: Note that we don't currently know for sure whether server support for bindings will be a requirement, either in the dogfood phase or later. Chandler supports bindings internally: in Chandler terms, an item appears in multiple Item Collections. In WebDAV terms, the closest modeling to that would be to upload the item to either Item Collection, then add a binding to it in the other collection. This would have pretty good interoperability with standard HTTP and WebDAV clients, because those clients would not need to support bindings in order to download the resource, it simply appears in both places. There are a couple possible backup plans. (1) is to upload the full content for each item into each shared collection it appears in. This creates work for the publishing client to keep the item in synch in each place it appears, because clients that aren't aware of the relationship between the two URLs could make different changes to each one. (2) is to make "soft link" resources in some places, where the soft link resource has a URL to the real resource -- and this kind of resource wouldn't natively be supported by other non-Chandler clients.

Interoperability

Although interoperability with non-Chandler software isn't strictly a Dogfood requirement, it might be good to demonstrate interoperability with one other piece of software, if they're willing to meet us halfway or if their model is easy to use. This could be a stretch goal for dogfood.

Bloomba: Raymie Stata indicated that interoperability was interesting to him. If Bloomba moves towards an event<==>resource storage model (rather than calendar<==>resource), particularly if they move towards the CalDAV model, we could also move towards that and possibly demonstrate interoperability. This would consist of, at a minimum, that a Bloomba client could publish their calendar to a WebDAV server and a Chandler client could download it (import), and vice versa. It could possibly also consist of shared authoring. This work would lead us towards a later goal of being CalDAV compliant.

Apple iCal: We could add support for importing an Apple iCal calendar into a Chandler Item Collection. This would be a natural extension of Jeffrey's existing iCalendar import work.

For the server, this can all work with a minimum RFC2518 implementation, not supporting any extra features.

Security

Authentication: Only minimal authentication ability is really required to dogfood WebDAV-based sharing -- Basic authentication. This is sufficient because the connection can happen over SSL/TLS, which protects the password. Digest authentication is a post-dogfood feature.

OSAF-Hosted Solution

This phase, if we reach it, would have us hosting WebDAV storage space for early adopters of Chandler to share data. In this phase:

Quota: We'd need the server to be able to limit user directories total size. This could be difficult because it needs to measure property size if we continue to put all our data in properties. Currently servers that measure quota probably only do so for the body.

Access Control: Is standardized access control really required for hosting? Consider the alternative: a WebUI^?. Users would go to a Web site, enter their username and password, and be able to configure permissions for their account -- e.g. share the calendar with one person and the contacts collection with others. An example of this is Sharemation.com -- it happens to support standard ACL, but most of the ACL changes are done through the WebUI^? because so far client support isn't found very widely.

Extranet sharing: We envision some way of sharing with users who don't have local accounts. Currently this isn't widely supported functionality, nor is it standardized, though it could be. We'd need to decide when this functionality would be required, before making choices.

*Performance & scalability *: It would be conservative to budget some time or money towards server improvements that make synchronization work very efficiently, or towards scaling to more users if we find limitations here.

CalDAV support: The current proposals for calendar access require some further development on our part.

Westwood/productization phase

In the phase where we have customers who need to run their own Chandler server, we need a few more features:

Ease of install

Ease of configuration

Notification - This is the capability for changes to WebDAV resources to trigger notifications through XMPP, as currently envisioned. Notifications could improve the performance of synchronization and could also improve the user experience by picking up changes immediately, and minimize conflicts and out-of-date information. Currently notification support in WebDAV servers is not implemented anywhere though it's certainly now under discussion in standards groups.

Server Implementation Comparisons

If CalDAV requires ACL support we may see CalDAV servers that meet all the needs of Chandler server except the support for extranet sharing, and possibly performance and fucntionality. My guess is we wouldn't see something that met the ease of install/configuration, or notifications, without making our own requirements and contributing towards development.

Assumed features: Basic auth, SSL.

-- LisaDusseault - 13 Aug 2004