I¹m not sure that notifying the user of a conflict is really the right solution. its simply to complicated for the average user to deal with. We chose the approach of the last one in, wins. Its simple, easy to explain, and in our testing works very well with users. If one of the users disagrees with the change they can either press UNDO or discuss over chat with the last modifier to resolve their differences.
On 8/29/07 1:16 PM, "Joonas Govenius" <[EMAIL PROTECTED]> wrote: > On 8/28/07, Jonathan Chayce Dickinson <[EMAIL PROTECTED]> wrote: >> > >> > As for a conflict, the initiating entity could rectify this, the other >> > users could run and cry to her and she would give the benefit of the >> > doubt to the user who owns the first edit in her MUW history. Remember, >> > people are actively involved here, the initiator can always say, "right, >> > hold on" (she should have a lock all function) and then dig in and fix >> > it. Because of the highly interactive situation, conflicts shouldn't >> > turn out to be a disaster, or do I have it all wrong? >> > > > Something pretty important to realise here is that before you can ask > a "master" user to arbitrate the conflict you have to know that a > conflict occured. > > Now, if you know that a conflict occured, you probably know which of > the changes conflicted so why not undo both changes? Why involve a > third party to arbitrarily "fix it"? > > See http://coccinella.im/memo/sync if you haven't already. > >> > Locking is an age-old technique. If a user wants to edit a text >> > label/area they should first request to lock it, once they receive a >> > lock they can edit away and then release the lock. >> > > > At least in SVG based whiteboarding, you'd like to allow several users > to simultaneously append elements to the end of the same tree of child > nodes (of the <svg/> for example). In this case locking would be > problematic. > >> > >> > The only thing is that it >> > will have to be a diff log for not only the XML structure, but also the >> > inner text of each element (e.g. a paragraph element in a >> > word-processing document could be pretty long). >> > > > I agree. I've decribed the same behavior for editing parts of > attribute values in > http://www.xmpp.org/extensions/inbox/sxde.html#sect-id2252086 > >> > >> > I have digged up an interesting XML Diff library called 3DM, I will look >> > and see what it can do once I port it to C#. >> > > > Diff tools like 3DM can be used in two ways: to generate diffs and to > merge them. While the former is the more demanding part for 3DM, I > don't think it's directly relevant to the protocol how the clients > generate the diffs. The latter on the other hand, is relevant but > isn't the difficult part. The difficult part is handling diffs that > don't arrive in the "correct" order. > > > Joonas >
