#define AUTHOR "bwalker@musings.com (Brad Walker)"

/*
 * I'm not suggesting that streams (ie. i do this in lower case to make
 * the typing easier) give the hardware more that it's capable of.

Best not to mix case.  Someone else said it best:  "streams means something
entirely different when it is shouted (i.e., STREAMS)."  [There are streams
and then there are STREAMS.  One is copyrighted and screwed up by
the (then) AT&T UNIX developers, and one isn't.  Unfortunately for us,
the one that isn't is also somewhat incomplete at the moment.]

 *								   What
 * I'm suggesting is that streams gives the system the ability to better
 * buffer events (ie. async events) that happen when the system is not
 * really able to handle things.

You could theoretically do that in a zs driver, but you'd have to increase
the current buffer size.  It seems moot to do so, however, since for any
buffer size X, there is an application capable of generating X+N (N>0)
amount of information with which to fill it.

If the hardware can't tell the modem to shut up on an overflow, STREAMS
sure as hell isn't going to make the problem any better.

 * 
 * Also, streams gives you the ability to do some neat things like
 * modules.

There is this, but one must make sure that it is implemented properly
(read: intelligently and efficiently), and not overmodularize.  In a
modular structure, one hits the point of diminishing returns rather
quickly.  The more modules you have on the stack, the longer it's
going to take data to get from one side of the STREAM to the other.

Someone else said this too:  "STREAMS should have been named GUTTERS."

I don't know, I think "PUDDLES" or "SEPTICTANKS" would have been
more appropriate.

 * 
 * -brad w.
 * 
 */

#undef AUTHOR	/* "bwalker@musings.com (Brad Walker)" */




				--*greywolf;
--
Have A Nice Day [TM].
	(Have A Nice Day is a registered trademark of the State of California.)