Xref: utzoo comp.sys.nsc.32k:342 comp.arch:3707
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!eos!aurora!labrea!polya!andy
From: andy@polya.STANFORD.EDU (Andy Freeman)
Newsgroups: comp.sys.nsc.32k,comp.arch
Subject: Remote editing
Message-ID: <2099@polya.STANFORD.EDU>
Date: 2 Mar 88 01:15:26 GMT
References: <880@PT.CS.CMU.EDU> <177@anumb.UUCP> <585@naucse.UUCP> <1006@ur-tut.UUCP> <23506@hi.unm.edu> <862@astroatc.UUCP> <183@anumb.UUCP> <877@astroatc.UUCP>
Reply-To: andy@polya.UUCP (Andy Freeman)
Organization: Stanford University
Lines: 17
Keywords: supdup

In article <877@astroatc.UUCP> johnw@astroatc.UUCP (John F. Wardale) writes:
[Wardale suggests buffering output, shipping it close to display (e.g.,
 to something upstream from terminal, and then go transfer char by
 char.  Input "has" to be handled differently, unless program support,
 such as vi, is built into buffering agent.
 He's considering a controller, 8 ports, one 68k, which does the obvious
 things with a `loadable character-indexed "what-to-do" table.']

>This (of course) means that vi, emacs, jove, et-al. would have to
>be hacked (alot ??) to take advantage of such things.

Look at supdup, a protocol devised by Stallman (RMS of GNU fame) and
documented in an AI lab tech report (it might be an LCS report).  Not
only does it work, and he's measured it, but he claims that it doesn't
require much applications hacking.  Of course, his "not much" may not
agree with yours.

-andy