Goal

Chandler should be able to share items over different transports, including P2P transports like email, not just to a server which serves as the source of truth.

To make P2P sharing work, Chandler needs to have a system for dealing with conflicting changes to items, which may be received in different order by different clients. Eventually, Chandler should have UI to display clusters of related items, PPD has suggested that this system would be used to view the history of conflicting changes. For the moment, we don't have UI to do this, nor do we have UI to allow users to choose which versions of an item should be used. We're just automatically resolving conflicts.

Sequence and DateStamp^? attributes

One way of determining whether an item update is valid would be to use a date stamp and let the most recent change win. Unfortunately, PC's are notorious for having poorly set clocks, so it's easy to imagine situations where some updates would be rejected out of hand for having an old date stamp.

A slightly more complicated approach would be to track a sequence number associated with every item. Any time an update was sent out, the sequence would be updated. In low frequency sharing scenarios, users would only rarely make changes to an item without having the latest version, and the sequence number would avoid having a dependence on clocks.

Conflicts would still happen. The proposed way of dealing with them would be to ignore old sequence numbers (which isn't reliable in high volume situations, but we're not trying to make all kinds of email sharing work, here). If sequence numbers were equal, we'd fall back to a date stamp, which is still unreliable but at least every recipient would at least then make the same decision about what update to use (the update whose date stamp was the latest).

There are still lots of ways for this to not work perfectly. If a user with an old version of an item sends an update to the item out to collaborators with a more up to date version, the updates will be ignored. There's also potential confusion when an item is shared in multiple ways.

Sharing via Cosmo and from email

Right now when sharing detects a conflit with Cosmo, the server wins. I think it would be reasonable to do a variety of things when sharing with both Cosmo and through email. We could:

1. Continue to let the server win, publish sequence number but ignore it when syncing, only increment sequence when an email update is sent out.
2. Track sequence and date stamp on the server, and use the same heuristic for resolving conflicts in server sharing as with email
3. Let the client win conflicts (to be consistent with "the most recent change wins" in email)

or I'm sure there are lots of other possibilities.

I don't think either of these options is perfect. Automatically merging and resolving conflicts is just never going to work perfectly. I think A) is the simplest thing to do, given the infrastructure we've already got.

In more detail, lets have client server sharing continue to make the server win, with one minor caveat. To avoid having wildly varying sequence numbers between email and server sharers, the largest sequence number should win when a server sync happens. This means occasionally Chandler will make a change to an item that only consists of a change to the sequence attribute, which will be a little weird since sequence presumbably won't be visible in the UI, but this doesn't seem like a particularly significant quirk.

Merging

We decided at our recent meeting that no merging of changes would happen when an item update was received through email, because merging in local changes would make it difficult to interpret the "updated by" field. But we'll continue to do client server merging as usual.

Failure Modes

Some odd situations can arise when the server wins conflicts, and the latest update wins. A relatively minor issue might happen if:

1. Person A shares an item with persons B and C
2. B sends out an update to A and C
3. B syncs to the server
4. C receives A's original item, but not B's update
5. C sends out a later update to B's item
6. C syncs, reverting backwards to B's version of the item
7. A receives B's update, then C's update (keeping C's version)
8. B receives C's update, keeping C's
9. B syncs, updating the server to C's version
10. C syncs, reverting back to C's version

Person C's version of the item will have followed an odd path, but everyone ends up at the same place eventually.

Perhaps a worse case would be if two different pairs of people get an item from a read-only share, then each pair makes a long series of email updates to the item. If the two pairs start sharing with one another, it's impossible to know which update will win. This is a similar problem to the situation when the same item is actively edited in multiple collections. Ultimately I think the solution to this would be to allow users to see the change history for items, but until we get there, I think this system should work reasonably well.

-- JeffreyHarris - 04 Dec 2006