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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
