Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!pyramid!csg
From: csg@pyramid.UUCP (Carl S. Gutekunst)
Newsgroups: comp.terminals
Subject: Re: What's wrong with flow control?
Message-ID: <1132@pyramid.UUCP>
Date: Wed, 3-Dec-86 13:46:11 EST
Article-I.D.: pyramid.1132
Posted: Wed Dec  3 13:46:11 1986
Date-Received: Wed, 3-Dec-86 22:30:44 EST
References: <3660001@nucsrl.UUCP> <7362@utzoo.UUCP>
Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 21

In article <7362@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>  What's needed is a "give me N more
>characters" protocol rather than a "stop right away, I'm full" protocol.
>To really work well, it would have to be standardized so that all terminals
>spoke the same protocol.  Don't hold your breath waiting.

There was an alternative that never really caught on: ENQ/ACK handshake, where
it was the responsibility of the host to send an ENQ every 'n' characters, and
wait for the terminal to send an ACK. The oldest terminal I can remember using
this was the HP 2640 series (which ain't that old). A number of other vendor's
terminals and printers in the late 1970s also supported this handshake, but
lately I've only seen a few printers that do.

None of the standard UNIX tty drivers support ENQ/ACK; for that matter, I'm
not aware of any OS/computer vendors besides HP and Burroughs that do, and
Burroughs only does so to support HP2641 terminals on its online frontends.

Of course, I'll bet that Gnumacs is already doing something special with ENQ
<CTRL-E> and ACK <CTRL-F>....

<csg>