SRA@XX.LCS.MIT.EDU (Rob Austein) (10/06/87)
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.