> > in a word:
> > no.
> 
> If I can ask you to expand a bit, is that "no" as in "no one has given
> it any thought" or as in "anyone offering a STREAMS implementation would
> be shot on sight"?
> 

no one has offered one.  This is not a shot on sight kind of thing at
all, assuming the author has written an efficient STREAMS....

> STREAMS is a pretty cool I/O architecture, but its chief advantage is
> kind of minimized if you've already got a perfectly reasonable TCP/IP
> stack (and if Van Jacobson's 100-instruction-tcp/ip changes manage to
> work their way into NetBSD (they're supposed to be in 4.4BSD), there'd
> be absolutely no excuse whatsoever for putting up with STREAMS' performance
> woes).

Van's stuff won't make 4.4-lite as I understand it.  I believe his
changes result in less of a layered protocol stack than we are used
to.

> 
> STREAMS as a research toy could be quite interesting; STREAMS as a
> networking philosophy would probably not adequately reward the immense
> expense of doing them to specifications (remember, after the initial
> STREAMS implementation (piece of cake), you've got billions and billions
> of poorly-thought-out modules to implement: TLI, XTI, XTISO, EIEIO, ...).
> 

no argument.

> About the only compelling advantage for a full STREAMS implementation
> would be a desire to be able to call NetBSD "UNIX" by passing the
> Spec 11,700,000 test if and when they finally finish it -- and I still
> suspect that if it DOES finally come to pass, the charge for being tested
> will be about as expensive as a USL source license...

:)

> 
> Given that, leaving STREAMS as an exercise for the interested student
> isn't unreasonable.

right, but we are not inherently opposed to such a thing if it showed
up, performed well, and didn't otherwise make our lives miserable.

later,
ADam Glass

------------------------------------------------------------------------------