MAP@LCS.MIT.EDU (Michael A. Patton) (11/18/89)
The discussion about whether to emulate something that exists or to invent your own has come around to the reason the SUPDUP protocol was first invented. Here's a short quote from the discussion to show where I'm starting from: >Think about it for a minute. What's the difference between emulating >an obscure but real terminal and "emulating" a nonexistent terminal? The first may be in the "termcap"/"terminfo"/whatever database on some remote system you log into, while the second may not be - and you may not have control over the remote system. The whole idea behind SUPDUP was to localize the detail knowledge of how to control specific terminal devices (or windows emulating terminals) to the system they are direct (or first) connected to. If you SUPDUP (rather than TELNET or rlogin) to another system, the protocol specifies how the display operations look "on the wire" and the local (to your terminal) system translates these into appropriate ESC-sequences or window system calls. The remote system only needs to know the "terminal type" supdup to support any and all connections. SUPDUP is not exactly a single "type" but rather a class, the details are communicated at connection setup. This is part of what kept it from being adopted on many systems when it first came out, but there are now implementations of both client and server for many types of systems. As an example, the UNIX server will take this and create a termcap entry on the fly, on older UNIX systems this was hard to keep straight but it works marvelously with more recent ones. As systems approach the flexibility and features of the ITS terminal driver (which SUPDUP is modeled after), it becomes easier and easier to support the function. It has always seemed to me that a marriage of X and (client) SUPDUP would be a good way of utilizing the features of this fancy display on my desk when connected to machines that don't know from xterm, but do speak SUPDUP (this would be approximately 1/3 of the machine types I deal with). __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-)
root@LARRY.MCRCIM.MCGILL.EDU (el Root) (11/18/89)
> The discussion about whether to emulate something that exists or to > invent your own has come around to the reason the SUPDUP protocol was > first invented. Supdup is a network protocol, not a choice of terminal to emulate. It's up to the supdup server what sort of virtual terminal to provide to programs running on the remote end of a supdup session. And the choice of that emulation is what we're discussing here, albeit in a slightly different context. Unless I missed something in my pass through RFC734.... In the meantime, I'll just note that if the remote system doesn't support the terminal type I'm emulating, I'll bring across my own termcap file and use it. If the remote system doesn't support supdup connections, as far as I can see you're SOL, unless you're fortunate enough to be able to install new network servers there. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu