Fowarded by request: ----- Forwarded message from Big Mike Forsberg <[EMAIL PROTECTED]> -----
Date: Sun, 18 Jan 2004 12:07:23 -0600 From: Big Mike Forsberg <[EMAIL PROTECTED]> To: Daniel Brown <[EMAIL PROTECTED]> Subject: Re: [Siglinux] Another groups disscussion. [EMAIL PROTECTED]: RE: [AustinJUG] Sharing keybuffers over computers.... Possible?] I think there are simpler ways to solve this... Infact vim uses one of the ideas already. Idea 1 - The modifier roll is passed changing the real life roll of person A and person B. Consider to real life programmers person 1 ansd person 2. Either could assume the roll of editor A or editor B. The only condition is that the editor B roll always exists as the modifier of editor's A buffer. Thus both person 1 and 2 can exist as standard A editors using "CVS esque merges" every sync time unit. The buffers are updated and nothing is really lost. (Think of editing code with a thread that performs a CVS merge every .5 seconds. Person 1 and 2 IDE keeps the display of code from jumping arround. Just ignore the scroll bar :) ) Thus nothing new. The cool part arises where Person 1 and 2 start to work in the same text unit. One of the people stays an A editor while the other enters the new B style editor. In the editor B roll text may be added at any point using the a rule like "no deletion of code that was not entered by editor B" instead just mark them for deletion. Then editor A could import the changes at some update point. In the pair programming example it would be ideal, because things like lost semi-colons would be easy to accept. Second idea is to treat the text as a quake style arena. In which case the use of vectors of text may be treated and warnings may be used when the vectors collide. At which point a small Mortal Combat style game would start and the winner get his/her text commited.... lol (The vector part was serious at least. I'm moving into my apartment today otherwise I'd clean this up and make it a little clearer. Big Mike P.S. I might also like to think of it in terms of applying a time out on text blocks. If the text has not be touched for a while then it may be safe for the other user to edit it with out a collision occuring. On Sat, Jan 17, 2004 at 12:42:53AM -0600, Daniel Brown wrote: > 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. -- Auto generated sentence : The 911 file in Munich is blue. ----- End forwarded message ----- -- Daniel Brown www.cs.utexas.edu www.utacm.org _______________________________________________ Siglinux mailing list [EMAIL PROTECTED] http://machito.utacm.org/mailman/listinfo/siglinux
