Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!sri-unix!mab@aids-unix.ARPA
From: mab@aids-unix.ARPA
Newsgroups: net.unix-wizards
Subject: Re:  VT100 and bagbiting
Message-ID: <1377@sri-arpa.UUCP>
Date: Thu, 28-Jun-84 13:29:26 EDT
Article-I.D.: sri-arpa.1377
Posted: Thu Jun 28 13:29:26 1984
Date-Received: Sun, 1-Jul-84 04:39:38 EDT
Lines: 53

From:  Mike Brzustowicz <mab@aids-unix.ARPA>

Please be precise--RS232 and ASCII are two very different issues.  And, you
missed my point while seizing on the irrelevant.  My point was not that the
two end are or should be distinguished, but that historically, XON/XOFF flow
control started from the other side, and that history is therefore NOT a
good justification for the way it is now.

And, it does make sense to treat the computer and the human ends of a 
connection differently--their capabilities in terms of data handling are
VERY different, no matter what connects them.

RS232 DOES distinguish between its two ends, the data terminal and the data
set.  Flow control at that level is done by signals on control lines.  For
terminal connected by RS232 directly to a computer, this allows flow control
without using any characters (which one might want to be data).  Modem users
cann't get that because those control lines are not encoded and transmitted by
the modems.

I, too, watched the "evolution" of XON/XOFF from close up, from the bad old
days, starting with Teletype ASR-33's.  You may have found it natural, but
others have not (obviously, or we wouldn't be flaming back and forth :-)).

I agree that flow control is very handy, but XON/XOFF is not a very good
implementation.  For example, modem protocols could send signals which are
out of the frequency bands used for transmitting characters to virtually
connect the signal lines (Clear to Send is the RS232 signal that come to
mind) at the RS232 level--not the data stream level.  You will find some
zealots (I'm not one) who insist that flow control belongs there and ONLY
there, at least for things like opening the lid on a diablo to change the
ribbon.  (According to RS232, that should lower Data Terminal Ready, which
should stop the data flow--sometimes that is implemented by hanging up the
modem!)

Another kind of flow control is for viewing large amounts of data
comfortably.  That is why more exists, what some editor excel at, and why
some have terminal paging in their kernels (Not that I want to start THAT
one again).


In the end, however, if your terminal and your operating system or editor
evolved so they are incompatible, you are free to change components to
attain harmony again.  Try 'ed'--it doesn't use any non printing charaters
for editing commands.  Or try a better terminal.  rebind your keys in EMACS
so that your favorites are free for flow control--or change your flow
control characters on your terminal (make a termcap entry that will change
them to nulls at start up and back to XON/XOFF at finish down--or can't your
terminal be programmed like that remotely?).  But please don't suggest that
all the systems that predated XON/XOFF flow control (for terminals) should be 
retrofitted to match that de facto, poorly done standard--I don't believe
that's a good idea and I doubt you'll change my mind on that.

-Mike