Re: supdup protocol and local editing

Alan Klietz (ihnp4!meccts!mn-at1!alan@ucbvax.Berkeley.EDU)
17 Oct 87 20:43:10 GMT

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 (

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:35 GMT