On Sat, Jan 17, 2004 at 12:12:57AM -0600, Anthony Liguori wrote: > Daniel Brown wrote: > > >But won't the users all be sharing the same cursor? I think Mike is > >looking for independent, simultaneous editing by multiple clients, IIUC. > > > >danb > > > > > Now we're getting into a terribly difficult programming problem. How > does one regulate two clients simultaneously editing the same buffer? > Let me give you an example: > > Say client A makes a modification to the buffer by removing one > character at position n. At the same time client B (or at least before > client B receives notification from client A) makes an addition to the > buffer at position k. However, the value of k is dependent on whether n > gets processed before or after k does. Obviously some sort of locking > mechanism is needed. So does one user lock a buffer, make some changes, > then unlock and let the other one go? Don't we lose simultaneous > editing though if we do this? > > I'm not saying it's not a good idea, I just think having multiple > independent cursors may be less usuable than you would initially think.
Difficult, sure, but not impossible from a usability standpoint. To the user, all that's really important is the position relative to the surrounding characters, and not so much the absolute byte offset in the buffer. For instance, if I'm editing some for loop and another user removes a large block of text above me, my only concern is staying at the same position within that code segment. As you suggest, it would be necessary to synchronize edit actions (and possibly even user position modifications). With this in place, we could simply update the positions of cursors beyond the current edit by an offset equal to the byte-length of the edit. If done correctly, affected users shouldn't even notice a change (unless, of course, the edit is viewable in their window). And in the case of overlapping edits, perhaps edit ranges could be checked, and invalid/conflicting edits (all but the first, determined within the aforementioned synchronization framework) could be dropped or raise some error to the submitting user. danb -- Daniel Brown www.cs.utexas.edu www.utacm.org _______________________________________________ Siglinux mailing list [EMAIL PROTECTED] http://machito.utacm.org/mailman/listinfo/siglinux
