dan@WILMA.BBN.COM (10/14/87)
> Some work was done a number of years ago (... at Arizona) to > investigate how to use a micro to do editing across a 1200 baud link. > They ... [applied] a "virtual editor" model at the backend ... > Editing commands across the link operated on lines, not characters, > though that wasn't necessarily the interface presented to the user. I don't know the work at Arizona you refer to, but I did something very much like this back when I had an ECD MicroMind micro in my office in 1979. The MicroMind had a "terminal program" which was also a full-screen editor. To edit a file, I sent over the lines I wanted to change, edited them for awhile, then sent them back. The "protocol" across the line "operated on lines, not characters," and was about as lightweight as you could get: it was the Unix "ed" line editor command set! To edit a file, I would invoke ed on it, print a range of lines, edit them locally, then send a change command to put them back in the ed buffer. Keyboard macros in the MicroMind made it all quick and easy. Like other people, I was very willing to put up with a few seconds' wait at the beginning and end of my editing to get an instantaneous response to each keystroke (and other advantages, such as a real meta key). This was done at 2400 baud, because Unix couldn't receive characters any faster without flow control (which the MicroMind didn't have). Sending over integral numbers of lines was just right, since that's what your local editor wants to deal with anyway. It also means you can easily handle having two different representations for "lines" (records vs. streams, crlf vs. lf, etc.) on the two machines. Also, if the backend "editor" can mark the beginning and end of each region sent to the local micro in a way which does not change as lines are added or deleted outside each region (which ed had), then you can trivially have independent windows on the same file at the same time with virtually no local "intelligence". Dan Franklin
kent@DECWRL.DEC.COM (10/14/87)
Ah. I was off-base -- the work was done at Rutgers, not Arizona. The full reference is DCS-TR-110, "Software Design Issues in the Architecture and Implementation of Distributed Text Editors", Robert N. Goldberg, Dept. of Computer Science, Hill Center for the Mathematical Sciences, Busch Campus, Rutgers University, New Brunswick, NJ 08903. I don't have a copy, so I can't tell you more, but I'll repeat what I recall of the basic premise: the display/user interface portion ran on a PC and accessed the file through a line editor interface, across a 1200 baud line. The PC viewed the whole file in a manner reminiscent of virtual memory. The author developed a concept he called "optimal pre-fetch", based on keystroke analysis of various editors, to allow the PC half to minimize the time the user spent waiting for lines to be fetched across the link. Seems like a good place to start looking, for someone looking to implement this sort of system. I believe that a simple editor makes a better interface for this sort of work than a full-blown remote file system, but it means that youre implementing a fairly special-purpose interface. In this day of faster communication, it may no longer be worth the effort. chris
alan@mn-at1.UUCP (Alan Klietz) (10/17/87)
In article <8710140650.AA03966@ucbvax.Berkeley.EDU> dan@WILMA.BBN.COM writes:
<
<To edit a file, I sent over the lines I wanted
<to change, edited them for awhile, then sent them back. The
<"protocol" across the line "operated on lines, not characters," and
<was about as lightweight as you could get: it was the Unix "ed" line
<editor command set! To edit a file, I would invoke ed on it, print a
<range of lines, edit them locally, then send a change command to put
<them back in the ed buffer.
<
<Sending over integral numbers of lines was just right, since that's
<what your local editor wants to deal with anyway. It also means you can
<easily handle having two different representations for "lines"
<(records vs. streams, crlf vs. lf, etc.) on the two machines. Also,
<if the backend "editor" can mark the beginning and end of each region
<sent to the local micro in a way which does not change as lines are
<added or deleted outside each region (which ed had), then you can
<trivially have independent windows on the same file at the same time
<with virtually no local "intelligence".
<
I wrote a program named "rvi" which does just this, albeit you need
a computer instead of just a smart terminal. It fetches multiple
screenfuls of text into a sliding window on the file. (See Volume 7
of the source archives.)
While this scheme gives you low overhead to the host, and avoids
the need to have single-character I/O and short RTTs, it loses
on slow networks (although some fancy window-prefetching can mitigate
this somewhat.) It also loses on flexibility (there are some vi
commands that you cannot bloody do with ed). And you don't get the
file recovery capability of real vi.
Of course, you could build a smart remote editor server and fix some
of these problems. But for portability, remember that ed and ed
clones are everywhere.
-Al (alan@uc.msc.umn.edu)richb@dartvax.UUCP (Richard E. Brown) (10/19/87)
At Dartmouth, we have been using just such a front/back end editing scheme for 5 years. The initial implementation was a Z-80 box with 32K RAM and 24K ROM which acted as a screen manager for a simple terminal and talked to a back-end editor on a host. This setup did two things: a) it provided "scrollback" of the last n lines of your session (limited by the 32K RAM), and b) cached a copy of the hosts file, to provide local editing. Editing changes were shipped back to the host, line-by-line. We had several hundred around campus, with good results. We now have a Macintosh version which uses the same back end editor (now implemented on Unix, VAX/VMS, and DCTS, with VM/CMS to come). The Mac provides much more scrollback, and places the screen editing text in a separate window. It uses the standard Macintosh cut-copy-paste paradigms. Rich Brown Telephone: 603/646-3648 Manager of Special Projects E-Mail: richard.e.brown@dartmouth.edu Dartmouth College richard.e.brown@dartcms1.bitnet Kiewit Computer Center richard.e.brown@dartvax.uucp Hanover, NH 03755 AppleLink: A0183
bdale@winfree.UUCP (Bdale Garbee) (10/19/87)
In article <8710140650.AA03966@ucbvax.Berkeley.EDU> dan@WILMA.BBN.COM writes: >Sending over integral numbers of lines was just right, since that's >what your local editor wants to deal with anyway. It also means you can >easily handle having two different representations for "lines" >(records vs. streams, crlf vs. lf, etc.) on the two machines. Also, >if the backend "editor" can mark the beginning and end of each region >sent to the local micro in a way which does not change as lines are >added or deleted outside each region (which ed had), then you can >trivially have independent windows on the same file at the same time >with virtually no local "intelligence". I spend a lot of time each day using an HP terminal tied into an HP3000 system dealing with HP's corporate mail system. The editor in the mail system works in a very similar fashion, but I find it nearly unbearable. I guess it depends on what you are used to, but using terminal-level intelligence to edit portions of files/messages is a problem, particularly when you want to clip and yank hunks of text that cross the boundaries of what you have in the local terminal. In particular, all of the systems I've used of this type require contortions to insert a large hunk of text in the middle of a file/message. The system described (using ed commands and a smart terminal) is a neat trick, but I'd like to see us avoid designing a protocol based on that model. -- Bdale Garbee, N3EUA phone: 303/495-0091 h, 303/590-2868 w uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa}!winfree!bdale arpa: bdale@net1.ucsd.edu packet: n3eua @ k0hoa, Colorado Springs fido: sysop of 128/19 at 303/495-2061, 2400/1200/300 baud, 24hrs/day