Proposal for managing user addresses in 0.5

In 0.5 we're starting to need to correlate several pieces of information about another user. There are several situations where this is needed:

• When I enter somebody's email address to share a collection with them, my client needs to know what that other person's WebDAV server userid is, in order to grant permissions to that userid.
• When I enter somebody's email address to schedule a meeting with them, my client needs to know the location of that other person's WebDAV account, to find where their free-busy information is shared and download it.

Proposal: Chandler should keep track of people with whom we have sharing relationships, and we populate that information via WebDAV.

1. As soon as a user (say "Alice") enters her WebDAV account information into Chandler, Chandler configures the WebDAV collection with properties about Alice. We add these properties to the collection:
   • Known email addresses
   • Full name
   • Local login name (userid) for permissions purposes
   • Location of free-busy data
2. Later, if this configuration information changes (e.g. Alice adds an email account that wasn't known before), the Chandler client updates this on the server.
3. Now that Alice's information is published (either publicly readable, or at least readable to all people she wants to be able to get at her freebusy), other people can stumble open this information by browsing to Alice's sharing collection.
4. When Alice sends a sharing invitation, it tells other people what her account location is. Therefore the recipient of a sharing invitation should always go to the published URL to find Alice's addresses and cache them for later use.

The main drawback to this design is that if Alice has not yet sent me a sharing invitation, I don't have her addresses cached. If I want to share something with Alice and type in her email address my client does not yet have the information to grant permissions to Alice or view freebusy. In fact, for all my client knows, Alice may not even be a Chandler user. We need to consider whether, in this circumstance, we assume that Alice is not a Chandler user (or a Chandler user without WebDAV access), or whether we ask the user to browse to Alice's sharing location to discover this information.

Brain dump from Stuart

Repository versioning: items become dirty in the repository when the item's order has changed in the repository. In the WebDAV view of the world that's not part of the item, it's part of the Item Collection. So we don't think it's really dirty.

John made a change so that inclusions, exclusions, results cache are all attributes on an Item Collection. Now the Item Collection becomes dirty...

A shared Item Collection works differently than a local Item Collection. A local Item Collection is stored as a query, but it's shared as a list of inclusions. These are actually rather inconsistent... the person who downloads this collection has an inclusion-based collection. There will be problems when the sharee adds something to the collection which the rule on the sharer's Item Collection doesn't think should be there. Also Item Collections are cumbersome to work with.

One possibility to deal with this is that a shared collection might become static, unless it's read-only.

Clouds make this worse. The person downloading content does a lot of round-trips to find out what's in the cloud and downloading them and following links until completed. A client that has made changes locally needs to do two passes: the 1st pass downloads changes from the server, the 2nd pass looks through for anything that was dirty in the clouds (but wasn't downloaded in the 1st pass) and uploads those items.

To do merging, we'll need to precompute what's changed locally, There's a "mapHistory" method that tells you what changed in the repository and Stuart's code really calls that a lot -- once per item. The right way to do this would be to save a version number (checkpoint) for the repository when a synch pass is done, and then refer to that checkpoint to see what's changed between the checkpoint and the current thing. Then go through that list and pull out everything that's shared.

Stuart's thought about storing a cloud as a single resource to reduce synch effort.

Apparently we already have a number of "backends" for the repository. One is database, one is XML files. You can have one or the other. This may be overdesign; I don't understand at this point what purpose that serves and whether that purpose is worth the effort.

-- LisaDusseault - 12 Oct 2004