[Design] Scoping out sharing-related 0.7 projects

[Morgen Sagen]

On Feb 6, 2006, at 4:50 PM, Mitchell Kapor wrote:

> I want to offer a different perspective on handling conflicts.  For  
> the sake of simplicity, let's assume there are two users, A and B,  
> each synching once an hour hour.  (I don't think we are going to  
> support more frequent synching due to issues with managing server  
> load.)  When synching is done with this frequency, if two people  
> change the same item and attribute such as to create a conflict,  
> there is no reason to prefer one to the other, even though, by  
> definition, one change is going to hit the server first.  We have  
> to stop thinking that one change precedes the other.  From a God's- 
> eye view it's true,  but from the user's perspective, changes  
> occurring in the same synching period happen essentially  
> simultaneously.  Here's a worked out example.
>
> Let's assume A is scheduled to sync at 15 minutes past the hour and  
> B at 30 minutes past the hour.  (To balance server load, time time  
> of synching should be chosen somewhat randomly).  Now A makes a  
> change at 12:00.  At 12:15 A's change hits the server.  Now let's  
> say B changes the same item at 12:20.  B won't see A's change since  
> the last time B synched was 11:30.  As far as B is concerned, B is  
> editing an unconflicted calendar.  When B syncs at 12:30, a  
> conflict is detected.  What should happen?

At 12:30, B would automatically download A's 12:00 change, A's change  
would "win", and B's local 12:20 change would be stored in a Conflict  
Notification to be resolved at B's leisure.

> Let's also assume, not unrealistically, that B isn't at the  
> computer at 12:30 to notice the change.  If "last sync wins" then  
> when A comes back to the computer at 1:20, A's change has been  
> blown away.  A says to self: WTF?

As implemented today, the last sync doesn't win.  It's the first sync  
that wins.  A's 12:00 change wouldn't be blown away in this case --  
A's change remains both on the server and in A's repository.   
However, say B gets back to his desk at 1:00 and notices the Conflict  
Notification in the sharing log.  If B feels that A's change is okay,  
he does nothing; otherwise if B wants his 12:20 change instead of A's  
12:00 change, he clicks an "I want my change to win" button or  
something.  At 1:30, B's change would go to the server and at 2:15,  
A's client would sync, B's change would appear in A's repository,   
and A would get a Change Notification in his log.

> (It could even be argued that A is being punished for being prompt  
> in the case both A & B noticed a problem with same event but chose  
> different ways to fix it.)

Actually, it's the early bird that wins in the current implementation.

> Also, whether a change is over-written or not will be a random  
> function of when the user's computer is set to sync vis a vis  
> someone else's computer.  I think this will make people crazy.  If  
> A made a change at 12:00 and B a change at 12:20, but it happened  
> that A was synching at 25 past and B at 22 past the hour, then A's  
> change would win.  In this case A would get what was expected, but  
> B would be going WTF.  It's the opposite outcome as before even  
> though A's and B's behaviors were identical.

In this case, B's 12:00 change would go the server at 12:22, A would  
download it at 12:25, B's change would "win", A's local change would  
be logged in A's repository as a Conflict Notification.

>   It would be very disconcerting to have who wins and who loses  
> essentially be random.  I think users will find it plain  
> unacceptable.  It will create enormous support headaches trying to  
> explain it.
>
> A change made later on the clock but between two sync periods don't  
> really happen "later" from the user's point of view.  The changes  
> happen "simultaneously".  Maybe a better way to put it is that any  
> two changes being made within an hour of each other happen more or  
> less simultaneously as far as the user is concerned (when synching  
> is only done once an hour, which is the driving assumption.  If  
> synching were instantaneous, these issues would not arise.

It's always going to be the case that one user's changes make it to  
the server before the other user.  The second client to sync is  
always going to have to be the one to perform conflict resolution,  
unless we change our model of how the server stores items.  It's all  
about how we present the info to the user...

> The only right thing to do is to carry both version and let the  
> user decide.

Right, and this is the biggest question -- how we support presenting  
two versions of an item to the user (both from the UI design and  
engineering points of view).  You want the application to have both  
versions of the item co-existing in the repository as equals it  
seems, not a winning change and a losing change.

> If, as a matter of simplifying the UI, one version was made  
> "authentic" but flagged and the other was carried along in some  
> sort of sidecar with the item (not in some separate log) and the  
> two were easily switchable, it would be ok with me but only on the  
> grounds of expedience.

As far as I know, when there is a sharing conflict, under the hood  
one version indeed needs to be the "winner" at the repository level  
-- i.e., those winning changes are applied to the item -- and we can  
store the losing changes somewhere for later access.  We can design  
the domain model to provide the UI with as much help as we can; for  
instance, having bi-directional references between Conflict  
Notification and the Item that had the conflict -- that way whatever  
UI is displaying an item has easy access to unresolved conflicts.

Anyway, I was just setting out to do an extremely simple UI for 0.7,  
since most of the work is going to be under the hood to allow for  
background synchronization.  I am fine with punting a fancy conflict  
resolution UI to a later release, but we should at least have  
Notifications of conflicts available to the user (which I proposed  
doing for 0.7 as a list of items in the summary table).  My simple  
0.7 conflict resolution UI was going to be a detail view that  
contained:  item name, attribute name, winning (remote) value, losing  
(local) value, and a button labeled with the equivalent of "apply my  
change instead"; just something to let us work out the kinks of  
dealing with conflicts at the framework level.


>> On Feb 6, 2006, at 2:18 PM, Sheila Mooney wrote:
>>
>>> I just wanted to point out that any kind of sophisticated  
>>> conflict resolution or versioning handling UI is out of scope for  
>>> 0.7. We will likely implement things in stages but the first step  
>>> for all of this will be to record the conflicts and log them in a  
>>> way a user can view them and manually make updates if they choose  
>>> to. Once we get that working (just to understand more about when  
>>> conflicts are happening), we can figure out what enhanced UI  
>>> would be the next logical step. Perhaps some of this will be done  
>>> during 0.7 but I think it's important to get something primitive  
>>> up and running first.