| 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? 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? (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.) 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. 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. The only right thing to do is to carry both version and let the user decide. 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. We went through a lot of these analyses when we designed Foxmarks (Firefox bookmark synchronizer) and this is where we came out. On Feb 6, 2006, at 2:48 PM, Mimi Yin wrote:
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
