lazarus@cs.odu.edu (Keith E. Lazarus) (04/19/89)
Do any of y'all know of any full-screen editors that support multiple
users editing a single file at one time???
So far as I know emacs doesn't support this and for some reason, I doubt that
vi, or ed do either :-) ........
Thanks in advance,
k.e.l.
--
=============================================================================
Keith E. Lazarus Department of Computer Science
lazarus@xanth.cs.odu.edu Old Dominion University Norfolk, VA
=============================================================================howeird@hpwrce.HP.COM (Howard Stateman) (04/20/89)
>Do any of y'all know of any full-screen editors that support multiple >users editing a single file at one time??? >Keith E. Lazarus Department of Computer Science Uh. I'm curious. Why would you WANT more than one person editing the same file at the same time? How would you keep someone from changing the same information that another is changing? Who gets the last change? In DBASEIII+, which allows this, the person who makes the last change wins. I would expect the same of a multi-user editor. -------------------------------------------------------------------- |Howard Stateman, Hewlett-Packard Response Center, Mountain View, CA | |howeird@hpwrce.HP.COM or hplabs!hpwrce!howeird | |Disclaimer: I couldn't possibly speak for HP. I know too much. | |--------------------------------------------------------------------| |Sysop of the Anatomically Correct BBS (415) 364-3739 | --------------------------------------------------------------------
lazarus@cs.odu.edu (Keith E. Lazarus) (04/21/89)
>> Do any of y'all know of any full-screen editors that support multiple >> users editing a single file at one time??? > Sorry, but I don't quite follow you. When would this be usefull, and > how on earth would you implement such a thing? > -- > Lars Bo Nielsen ( lbn@ksuvax1.cis.ksu.edu -*O*- ...!rutgers!ksuvax1!lbn) 1) when would this be useful??? i'm not exactly sure... thanks to separate compilation, there really shouldn't be a need to do this if the modules were broken down into a small enough size. even then, occasionally it might be convenient to allow two people, working at separate terminals, to access the same file concurrently. 2) how would such a creature be implemented? for a systems programming course that i'm taking here, i implemented a primitive full screen editor that supports this. to work around the problem of having two copies of the file being edited in memory at the same time, i used a server/client type arrangement. one server would exist for each file being edited and one client for each user. the server maintains a fairly current image of the file being edited. ( i say <fairly current> because the client only sends an updated copy of the line being edited when the user moves his cursor off of the line ) all character based operations (ie. adding/deleting characters) are performed by the client and all line based operations (ie. insertion/deletion) are performed by the server. also, the server is responsible for preventing multiple users from modifying the same line at line time. all of the interprocess communications are via sockets. i do realize that if several instances of this program were running that this could cause a fairly substantial load on a network, but nothing comes free....... ........... All this brings me back to my original question: >> Do any of y'all know of any full-screen editors that support multiple >> users editing a single file at one time??? and a new question: Can any of you come up with any other possible uses for such an editor? k.e.l. -- ============================================================================= Keith E. Lazarus Department of Computer Science lazarus@xanth.cs.odu.edu Old Dominion University Norfolk, VA =============================================================================
lbn@ksuvax1.cis.ksu.edu (Lars Bo Nielsen) (04/21/89)
In article <8531@xanth.cs.odu.edu> lazarus@cs.odu.edu (Keith E. Lazarus) writes: > Do any of y'all know of any full-screen editors that support multiple > users editing a single file at one time??? Sorry, but I don't quite follow you. When would this be usefull, and how on earth would you implement such a thing? -- Lars Bo Nielsen ( lbn@ksuvax1.cis.ksu.edu -*O*- ...!rutgers!ksuvax1!lbn )
lbn@ksuvax1.cis.ksu.edu (Lars Bo Nielsen) (04/21/89)
>1) when would this [multiple user editor] be useful??? > >i'm not exactly sure... thanks to separate compilation, there really >shouldn't be a need to do this if the modules were broken down into a small >enough size. even then, occasionally it might be convenient to allow two >people, working at separate terminals, to access the same file concurrently. > >2) how would such a creature be implemented? > >i used a server/client type arrangement. one server would exist for each >file being edited and one client for each user. the server maintains a >fairly current image of the file being edited. ( i say <fairly current> >because the client only sends an updated copy of the line being >edited when the user moves his cursor off of the line ) The way you have implemented this "creature" reminds me of parrallel processes. You have that two users can not edit the same line at the same time, while in an implementation of parrallel processes two processes can not write to the same memory-location at the same time (usely done by some kind of semaphores) (probably somebody could tell us a story of the differences between "concurrency" and "true concurrency" ?). From a more philosophical point of view this is an interesting discussion. Now we have set the limits, or lower bound, to a single line, we could model the file. Instead of saying that a file is one unit, we could say that a file is a collection of lines, and even say that these lines is in fact just files at a lower level. What the users then actually changes is the files at the lower level. Then the problem will be what to do when a new line is inserted. Well, if we model the origional file as a "directory", that is a collection of files at the lower level, this seems to finish the model. The new model of the filesystem will then be something like: Directories File-directories File-lines Could this be extended to, say Directories File-directories File-lines-directories File-characters or even further?? >and a new question: > > Can any of you come up with any other possible uses for such an editor? > No. >============================================================================= > Keith E. Lazarus Department of Computer Science > lazarus@xanth.cs.odu.edu Old Dominion University Norfolk, VA >============================================================================= PS: I am going back to Europe in a week, and I would like to follow this discussion, so I have changed the distribution to "world". -- Lars Bo Nielsen ( lbn@ksuvax1.cis.ksu.edu -*O*- ...!rutgers!ksuvax1!lbn )
loo@mister-curious.sw.mcc.com (Joel Loo) (04/21/89)
In article <1481@cfa.cfa.harvard.EDU> lbn@ksuvax1.cis.ksu.edu (Lars Bo Nielsen) writes: >> Do any of y'all know of any full-screen editors that support multiple >> users editing a single file at one time??? > >Sorry, but I don't quite follow you. When would this be usefull, It will be useful in collaborative working session, e.g computer-conferencing, group software engineering. Look up the various proceedings of the Conference on Computer Supported Collaborative Works (CSCW) and other similar papers for details. A portion of the works in CSCW addresses the problem of multi-user editing. There are no useful and marketable products yet since the technology is only 2-4 years old. >and how on earth would you implement such a thing? Need new user-interface paradigms and new coordination algorithms. Same thing: read up Proc. of CSCW. ----------------------------------- Joel Peing-Ling Loo Voice: 512-338-3680 _ _ Email: loo@mcc.com MCC (=E) .o|o( v )+-H- o 3500 West Balcones Centre Drive TO|O \ / | U | Austin, TX 78759 % | V ---/ \ [ Disclaimer: The above article/signature reflects only my own opinion; my employer has nothing to do with it. ]
budden@manta.NOSC.MIL (Rex A. Buddenberg) (04/22/89)
I'll beg off on the first question -- why would anybody want such an animal. Perhaps a crash editing session by the whole crew in order to get a Congressional out the door. But I can't see that being a successful, or even rational operation. But, how to do it. If we assume something about the construction, then we can apply database analogy. Assumption: the text is broken up into sentences and/or paragraphs that are recognizable by the editor. Then have the editor simply record-lock the sentence/ paragraph that you are working on so nobody else can touch it until you move on and the lock is removed. Exactly like record locking in a multi-user database management system. Rex Buddenberg
tim@scsmo1.UUCP (04/23/89)
>In article <8531@xanth.cs.odu.edu> lazarus@cs.odu.edu (Keith E. Lazarus) >writes: >> Do any of y'all know of any full-screen editors that support multiple >> users editing a single file at one time??? >Sorry, but I don't quite follow you. When would this be usefull, and >how on earth would you implement such a thing? >-- > Lars Bo Nielsen ( lbn@ksuvax1.cis.ksu.edu -*O*- ...!rutgers!ksuvax1!lbn ) Here at SCS we have a use for such a beast. Not very much use, but still It would get used. We also have need for a real word processor, thanks to ``word.'' I am currently writing an editor/wp (have been to 2 years!) and it takes very little extra to add this featrure. The buffer has a bit that tells if the line is shared or not. If it is shared it has more data in the structure to keep people from trashing each others work. The basic idea is that EACH line can be marked READ-ONLY. Of course the insert a line makes things real fun and since the data may be on the disk and not in memory, that has to be accounted for. tim@scsmo1.uucp Soil Conservation Service
uucibg@sw1e.UUCP (3929]) (04/24/89)
In article <764@manta.NOSC.MIL> budden@manta.nosc.mil.UUCP (Rex A. Buddenberg) writes: +But, how to do it. If we assume something about the construction, +then we can apply database analogy. Assumption: the text is broken +up into sentences and/or paragraphs that are recognizable by the +editor. Then have the editor simply record-lock the sentence/ +paragraph that you are working on so nobody else can touch it +until you move on and the lock is removed. Exactly like +record locking in a multi-user database management system. This solves the problem of changes to the existing contents of the file, assuming that you have some way of determining the scope of the changes that the user intends to make. That is, "Hmmm, is this guy(girl) going to change just this line or the whole paragraph?". Otherwise, gaining and relinquishing your locks could be expensive as all get out. However, this doesn't address the problem of deletion and insertion. In particular, what happens if two people try to insert a new paragraph at the same place? It's a solvable problem certainly, but synchronization becomes a bit more compilcated. I suppose you could have "hole locks" which would lock out other users from inserting new text between two given paragraphs. But that is not as nice as allowing multiple additions between paragraphs and assigning a particular semantics to such requests (though the first is a lot easier than the second, by a cursory examination). It would also be nice to have some sort of marker appear in the text of user A's display to let him know that user B is adding text between the two paragraphs. What other bells and whistles could we dream up? >Rex Buddenberg Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 ...!uunet!swbatl!sw1e!uucibg #include <std_disclaimers.h>
jhallen@wpi.wpi.edu (Joseph H Allen) (04/25/89)
In article <8531@xanth.cs.odu.edu> lazarus@cs.odu.edu (Keith E. Lazarus) writes: >Do any of y'all know of any full-screen editors that support multiple >users editing a single file at one time??? > >So far as I know emacs doesn't support this and for some reason, I doubt that >vi, or ed do either :-) ........ Now that's an interesting idea... we'll soon be seeing demacs (the editor daemon). Actually I have seen a multiuser editor in a boxed system (a cable TV channel controller/character generator). It was page based so more than one person could edit different pages in the same file. I wonder if there's any theory for making an editor which is truely multiprocessed- (I.E. no editor daemon).
nazgul@apollo.COM (Kee Hinckley) (04/26/89)
In article <8460001@hpwrce.HP.COM> howeird@hpwrce.HP.COM (Howard Stateman) writes: >>Do any of y'all know of any full-screen editors that support multiple >>users editing a single file at one time??? > >Keith E. Lazarus Department of Computer Science > >Uh. I'm curious. Why would you WANT more than one person editing the >same file at the same time? How would you keep someone from changing >the same information that another is changing? Who gets the last change? > Stop thinking programming languages. Think things like bugs files, where people can be adding bugs, updating existings ones, etc.. Think of interactive editing where I'm adding text and someone else is working on another part, or commenting on what I'm doing (much more efficient than having them stand over my shoulder and trying to tell me what to type). Lots of documentation may be the product of more than one person, or would be if it were possible to do this simply. Clearly you need to handle locking, and deal with what happens if two users try and modify the same thing, a SMOP. If DBase allows multiple users, and doesn't lock then I say it's broken. Unix has dones this for years with files, and it's broken too :-). File/Record locking is really mandatory for a consistant multi-user system. -nazgul -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
dig@peritek.UUCP (Dave Gotwisner) (04/27/89)
In article <8571@xanth.cs.odu.edu>, lazarus@cs.odu.edu (Keith E. Lazarus) writes:
#
# >> Do any of y'all know of any full-screen editors that support multiple
# >> users editing a single file at one time???
#
No. Sorry.
# 1) when would this be useful???
#
# i'm not exactly sure... thanks to separate compilation, there really
# shouldn't be a need to do this if the modules were broken down into a small
# enough size. even then, occasionally it might be convenient to allow two
# people, working at separate terminals, to access the same file concurrently.
#
An example of where this would be useful:
A project consists of two people. One is a hardware engineer, the other
is a software engineer. There is to be one manual for the project,
and to simplify maintenance, it is required that the manual be maintained
in one source file. Also, there is no source code control system for
the development machine (or management decides that SCCS is fine for
programs, but not for documentation, take your pick). While writing the
manual initially, both people could quite probably be in the file at the
same time (this could be gotten around by creating two files, one for each
person relating to their parts of the project, and merging them later).
Down the road, when updates need to be made to the manual, both users may
need to be in the file at the same time. If the two engineers are in
different locations, verbal coordination becomes difficult. An editor
which allows for simultaneous modifications to the same files becomes
quite useful.
# 2) how would such a creature be implemented?
#
# for a systems programming course that i'm taking here, i implemented a
# primitive full screen editor that supports this. to work around the problem
# of having two copies of the file being edited in memory at the same time,
# i used a server/client type arrangement. one server would exist for each
# file being edited and one client for each user. the server maintains a
# fairly current image of the file being edited. ( i say <fairly current>
# because the client only sends an updated copy of the line being
# edited when the user moves his cursor off of the line )
#
# all character based operations (ie. adding/deleting characters) are performed
# by the client and all line based operations (ie. insertion/deletion) are
# performed by the server. also, the server is responsible for preventing
# multiple users from modifying the same line at line time.
#
# all of the interprocess communications are via sockets. i do realize that
# if several instances of this program were running that this could cause a
# fairly substantial load on a network, but nothing comes free.......
#
Another way to do this would be to put the common data structures in
shared memory. All buffers which are read from disk are read into this
shared memory (rather than task private memory as is usually the case).
Many of the variables which currently go on the stack in a C or Pascal
implementation would also have to go into this shared memory region. Of course,
if you are running editors on two separate hosts, with the file residing on
a file server, this method would not work.
--
------------------------------------------------------------------------------
Dave Gotwisner UUCP: ...!unisoft!peritek!dig
Peritek Corporation ...!vsi1!peritek!dig
5550 Redwood Road
Oakland, CA 94619 Phone: 1-415-531-6500