Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SUPDUP protocol
Message-ID: <8994@think.UUCP>
Date: Mon, 5-Oct-87 12:42:02 EDT
Article-I.D.: think.8994
Posted: Mon Oct  5 12:42:02 1987
Date-Received: Thu, 8-Oct-87 04:40:46 EDT
References: <12338315541.10.BILLW@MATHOM.CISCO.COM> <870930102609.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Sender: news@think.UUCP
Reply-To: barmar@pozzo.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 33

This discussion of SUPDUP stemmed from a discussion of RCTE.  Several
people pointed out that SUPDUP doesn't actually solve the problem that
RCTE is intended to solve.  However, RMS long ago proposed a
SUPDUP-based solution, called the Local Editing Protocol (LEP), which
goes much further than RCTE.  LEP allows a host program to tell the
terminal emulator about many simple key bindings.  These include
self-insert, relative cursor motion, motion by words, and simple
deletion commands.  A large number of the operations of a video text
editor end up being performed in the workstation, and when the user
types a command it can't perform locally all the buffered up
operations are transmitted to the host, so that it can update its
buffer.

RMS also proposed a related protocol, called the Line Saving Protocol,
which allows the host to send lines outside the physical screen, or
the workstation can remember lines that are scrolled off and the host
can ask it to recall them.

I believe RMS actually implemented support for LEP in ITS EMACS, but I
don't think he ever wrote a client SUPDUP that implemented it.  Most
of the SUPDUP support in the world at the time was connected to MIT's
Chaosnet, and network speed was never a problem within that
environment (when supduping from a Lisp Machine to ITS they didn't
bother turning on insert/delete-line operations, because it slowed
down EMACS's redisplay computation, and redrawing the screen over the
net was faster!).

---
Barry Margolin
Thinking Machines Corp.

barmar@think.com
seismo!think!barmar