SUPDUP protocol, window systems, what issues are still current

Rob Austein (SRA@XX.LCS.MIT.EDU)
Tue, 6 Oct 1987 03:13 EDT

Granted that window protocols are a subject deserving lots of skull
sweat and are good clean fun. However, I don't think this eliminates
the continuing need for a "terminal" protocol (ie, something that
passes "keystrokes" in one direction and "characters" to be displayed
in a more or less boring and regular fashion in the other direction).

Two reasons for this:

 - Bandwidth, RTT, and cost constraints are still with us and
   presumably always will be. Dr. Malthus always has the last laugh.

 - Most of the researchers in my building have some kind of bitmapped
   display running a window system. Nevertheless, it seems that most
   of these people spend most of their time talking to two kinds of
   programs: command interpreters and text editors (both of these also
   come in various specialized flavors, such as lisp listeners and
   mail readers/composers). I believe that this will be the case as
   long as the primary mode of data input is a keyboard. While it is
   certainly possible and probably useful to hair things up with
   bitmapped graphics, people can get their work done using programs
   that operate within the "terminal" model. There is no particular
   problem with having the terminal model support mice; mouse clicks
   can be represented by a "character" followed by coordinates in
   terms of character positions (an existing library for Lispm mice in
   ITS/Twenex EMACS via SUPDUP does this).

Taken together, I think this points out a continuing need for terminal
support. In particular, I find it hard to believe that users faced
with a severe bandwidth or RTT problem will buy the argument that they
really want to be using a window system when they know that they could
be getting useful work done with a plain old terminal. Certainly one
can add hair to the window protocol to deal with these cases, but
doing so is essentially resurrecting the terminal protocol inside the
window protocol; you may decide that this is what you want, but it's
by no means an open and shut issue.

I agree with John Wroclawski about the direction any new work on
terminal protocols should take, so I won't repeat it.

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