Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ptsfa!ihnp4!meccts!mn-at1!alan
From: alan@mn-at1.UUCP (Alan Klietz)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: supdup protocol and local editing
Message-ID: <395@mn-at1.UUCP>
Date: Sat, 17-Oct-87 16:43:10 EDT
Article-I.D.: mn-at1.395
Posted: Sat Oct 17 16:43:10 1987
Date-Received: Sun, 18-Oct-87 23:29:59 EDT
References: <8710121554.AA07611@armagnac.DEC.COM> <8710140650.AA03966@ucbvax.Berkeley.EDU>
Reply-To: alan@mn-at1.UUCP (0000-Alan Klietz)
Organization: Minn. Supercomputer Center
Lines: 38

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)