Xref: utzoo comp.dcom.modems:3004 comp.sys.att:4799
Path: utzoo!utgpu!attcan!lsuc!ncrcan!ziebmef!cks
From: cks@ziebmef.uucp (Chris Siebenmann)
Newsgroups: comp.dcom.modems,comp.sys.att
Subject: Re: Verbose modems (Re: MORE 6386 UUCP WOES)
Message-ID: <1988Nov24.004706.7463@ziebmef.uucp>
Date: 24 Nov 88 05:47:05 GMT
References: <319@argon.UUCP> <2096@cuuxb.ATT.COM> <727@wsccs.UUCP> <889@vsi.COM> <758@wsccs.UUCP> <83@prapc2.UUCP> <2174@cuuxb.ATT.COM> <5203@cbmvax.UUCP> <6916@chinet.chi.il.us> <5212@cbmvax.UUCP>
Reply-To: cks@ziebmef.UUCP (Chris Siebenmann)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 26

In article <5212@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
...
>Why do you think this?  I have my doubts about using a new feature that
>was added in a way that does not work with commonly used software.  I
>think that the more sophisticated modems get, the dumber they should look
>to the computer; fixed bit rate, completely transparent flow control, etc.

 The problem with this is that at different baud rates the user may
wish drastically different behavior from programs, depending on the
baud rate she is at. Consider just two examples; the amount of text on
the initial page of an article rn shows, and the special low-speed
interactive search mode of GNU Emacs.

 Things that appear perfectly reasonable to the computer at baud rate
M may be highly undesirable or even impossible at the connection's true
baud rate of N (consider a status display program who's screen updates
simply push out more characters per second than N can ever transmit in
one second). The need for this sort of information won't go away;
since the modem can provide it and the computer recognize it, why not
use it?

-- 
	"The hell I will!"	WHAK!	"Surpise, kid -- they retract!
	 Try that again and I'll kick you back. With my claws."
Chris Siebenmann		uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!cks
cks@ziebmef.UUCP	     or	.....!utgpu!{,ontmoh!,ncrcan!brambo!}cks