lazarus@cs.odu.edu (Keith E. Lazarus) (04/21/89)
this isn't going at all like i had hoped it would.... i think i'd better answer a couple of your questions..... > Is this a joke? What possible use would having several people > editing the same file at the same time be? no, its not a joke..... for a systems programming course i took this past semester, i was required to design and implement a utility for UNIX that did not already exist. while discussing possible topics for the project with my professor, he mentioned the idea of a multi-user editor. since i'd been interested in the design of text-editors for a while, I decided that this would be an interesting program to write...... at the time, i didn't bother wondering about how necessary such an editor would be, however, as time went on - i began to see some of its strengths... personally - i don't feel such an editor is essential, it would just be a luxury. (the only time that i can recall ever wishing for an editor that supports multiple users was last semester when a friend and i were working on a project for one of our courses. we had 15 minutes till it was due and had to make a few modifications to two procedures. he was responsible for one procedure, I was responsible for the other and both were located in the same file. Consequently, he had to wait till I was finished and the phase ended up being handed in late.....) (note: this was before i learned how to change the 'last-accessed' time on files.. :-) ) my editor isn't finished, however, it does support multiple users simultaneously performing most of the basic editing operations on a single file (ie. insert line/character, delete line/character, etc.....). i expect that i'll have a reasonably useful implementation working by the end of the summer. > How would you keep someone from changing the same information > that another is changing? Who gets the last change? i briefly described how i went about this in a posting i made earlier today ( i think... ). if anyone wants a more detailed description of the algorithm, let me know - i'd be more than happy to supply it. -------- i'm really surprised at the reactions i've gotten when i've mentioned this idea to people... a very strange look and 2 questions: 1) why would you want to allow that??? & 2) how can it be done??? i now realize that this is a <<<new>>> idea, however, I don't think that it is too ridiculous. i'm really surprised that nothing like this already exists. i'm sure that at least one of y'all has wanted to make some changes to a file at one time or another, but was unable to because someone else was already editing that file. granted, you could use the conventional technique to solve this problem - go get a beer and come back later - i find this somewhat inefficient, though....... my original question still stands: > Do any of y'all know of any full-screen editors that support multiple > users editing a single file at one time??? i'd also still interesting in hearing about any 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 =============================================================================
mlr@cbnewsh.ATT.COM (michael.l.robins) (04/21/89)
There has been talk about what a multi-user editor might be used for. There have been various projects taking place at universities and businesses in the area of group-ware. That is to say, software that allows a group of people to interact electronically. Some of the studies have shown that this can be a very effective was to create new ideas and exchange information. Of course there are the issues of who types what where and when, but some of the solutions have been very creative. Locking of changing sentences or paragraphs have been one approach tried.
fox@cs.cs.columbia.edu (David Fox) (04/21/89)
It may be true that there are no editors that support multiple people editing the same file at the same time, but there is a tool that supports the concurrent editing of even more general data objects, and it is called...... A DATABASE! You may want to look at the database literature if you are planning on implementing such an editor. David Fox fox@cs.columbia.edu
lee@uhccux.uhcc.hawaii.edu (Greg Lee) (04/21/89)
From article <8583@xanth.cs.odu.edu>, by lazarus@cs.odu.edu (Keith E. Lazarus): " ... " i'd also still interesting in hearing about any possible uses for such " an editor... Some data base systems permit a data base to be edited simultaneously by several people. Editors can sometimes be used in data base applications. So this is one place to look for possible uses: lists whose items must be frequently updated by many people working independently. Transactions processing. Greg, lee@uhccux.uhcc.hawaii.edu
uucibg@sw1e.UUCP (3929]) (04/24/89)
In article <8583@xanth.cs.odu.edu> lazarus@cs.odu.edu (Keith E. Lazarus) writes: >i'm really surprised at the reactions i've gotten when i've mentioned >this idea to people... a very strange look and 2 questions: > > 1) why would you want to allow that??? & > 2) how can it be done??? > >i now realize that this is a <<<new>>> idea, however, I don't think that it is >too ridiculous. i'm really surprised that nothing like this already exists. Perhaps to the Un*x world. Though I think this may be a matter of a lack of need (the system which I know of which has such an editor has much more compelling reasons: it was quite a bit slower in user-repsonsiveness (and as near as I can tell, in general <in mips/$$>), and didn't support lots of smaller files as well as a few *huge* files). >my original question still stands: > Do any of y'all know of any full-screen editors that support multiple > users editing a single file at one time??? There is such and editor that runs under the MCP operating system on the Unisys (used to be Burroughs) A-series machines. It probably doesn't quite qualify since the inherant assumption in this discussion seems to be that the full-screen editor is asynchronous (along the lines of emacs or vi). The A-series machines use a poll/select approach (as near as I recall) so as a result you get more of a synchronous "feel" in your editing (you know, make a bunch of changes, hit enter, wait for the screen to come back). I was not at all impressed with the MCP operating system when I worked for Unisys (though I certainly can't claim that I knew it intimately). However, this editor definitely allowed multi-user access, with granularity down to lines. It also required that files have line numbers (ack!). > Keith E. Lazarus Department of Computer Science > lazarus@xanth.cs.odu.edu Old Dominion University Norfolk, VA 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>
koo@cortina.orc.olivetti.com (Richard Koo) (04/25/89)
Many people have wondered at the utility of multi-user editors. In
the "collaboration technology" community, two uses of multi-user
editors (among others) are frequently mentioned: (1) coauthoring a
paper/proposal/design and (2) tutoring.
In these situations, users are often in "conference" mode, meaning
that while one types/talks, the others watch and listen. This would
eliminate the obvious difficulty arising from many users typing at the
same time.
As for how a multi-user editor can be implemented, the short answer is
that it is probably not worth doing. The folks in the collaboration
technology community have opted for more general approaches such as
window sharing in which users will see the same window on their
screens/displays. This way, users can potentially share more tools
than just editors.
CSCW proceedings would be a reasonable place to look if you are
interested in more information on "collaboration technology."
--
Richard Koo | Internet: koo@orc.olivetti.com
Olivetti Research Center | UUCP: {...}!ames!oliveb!orc!koo
2882 Sand Hill Road | Voice: +1-415-496-6232
Menlo Park, CA 94025 | Fax: +1-415-496-6219hastings@pine.Berkeley.EDU (Mark Hastings) (04/26/89)
In last week's MacWeek rag, I saw an ad for a Macintosh "groupware" application that would be considered a multi-user editor. I believe it was from Farralon Systems here in the Berkeley area. Given the high quality of their Mac gurus, I would suspect it is more than just marketing hype.
borsom@imokay.dec.com (Doug Borsom) (04/28/89)
In article <1523@sw1e.UUCP> uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) writes: >... >There is such and editor that runs under the MCP operating system on the >Unisys (used to be Burroughs) A-series machines. It probably doesn't quite >qualify since the inherant assumption in this discussion seems to be that >the full-screen editor is asynchronous (along the lines of emacs or vi). >.... >...However, this editor >definitely allowed multi-user access, with granularity down to lines. It also >required that files have line numbers (ack!). >.... Actually the Burroughs/Unisys editor can function in "patch" mode, which allows any number of folks to work against the same base file. No changes are made to that base file during the editing session. For each user, the editor records only the delta, the differences between the base file and the changes that user made, although to the user, it looks like he/she is changing the base file. As Brian notes, the granularity is at the line level, and the editor uses line numbers as an index into the files. Each line is actually a record in the file. After the editing session ends and the delta (patch) file is saved, the delta file can be applied to the base file along with the delta files of others who might have been editing the base file. If conflicts arise (two or more delta files alter the same record in the base file), the utility that does the merging warns the user so conflicts can be resolved. A unique identifier is tagged onto the end of all the lines in a delta file, in a non-text area of the record. This provides a record of changes made to the base file. The system is used (among other things) by system programmers working on the Master Control Program, which is very powerful, very robust, and is well over 600,000 lines long. When I was with Unisys, there were programmers at sites on both coasts working on the MCP. The editor patch system allowed this to be done without total chaos ensuing.