Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!ksuvax1.cis.ksu.edu!lbn
From: lbn@ksuvax1.cis.ksu.edu (Lars Bo Nielsen)
Newsgroups: comp.editors
Subject: Re: multi-user editors???
Keywords: uses, feasible
Message-ID: <1744@deimos.cis.ksu.edu>
Date: 21 Apr 89 14:34:55 GMT
References: <8531@xanth.cs.odu.edu> <1736@deimos.cis.ksu.edu> <8571@xanth.cs.odu.edu>
Sender: news@deimos.cis.ksu.edu
Reply-To: lbn@ksuvax1.cis.ksu.edu (Lars Bo Nielsen)
Organization: Kansas State University, Dept of Computing & Information Sciences
Lines: 65

>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 )