Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!ucbvax!unisoft!peritek!dig From: dig@peritek.UUCP (Dave Gotwisner) Newsgroups: comp.editors Subject: Re: multi-user editors??? Keywords: uses, feasible Message-ID: <629@peritek.UUCP> Date: 27 Apr 89 08:57:54 GMT References: <8531@xanth.cs.odu.edu> <1736@deimos.cis.ksu.edu> <8571@xanth.cs.odu.edu> Distribution: usa Organization: Peritek Corp., Oakland, CA Lines: 67 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 # 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