For anyone needing context, STREAMS was SysV's competing API for I/O. https://en.wikipedia.org/wiki/STREAMS
>Regardless of what the wave of the future is, presently if you write to the TLI interface you won't be able to compile your code on a socket-only system whereas if you use the socket interface you'll be portable to most TLI systems (since they usually come with socket interface libraries). If you aren't concerned about optimal efficiency, writing to the socket interface now would be more portable.
> While RPC is good for some things, it is not the answer to all the networking problems. Sometimes you just gotta write at a fairly low level to interoperate with other programs.
Obviously, we now know that the OSI protocols didn’t get used (unless you count ldap or x509 or everyone talking about layers all the time) and so the more flexible api was not required.
This is super funny, but also a bit of a surprise for someone born after the referenced thread occurred. As someone who only learned about the "layers" model of networks in college more than two decades after the discussion, it never occurred to me that the original intent of the model was to describe forthcoming protocols from OSI; we were just told "this layer means TCP or UDP, this layer means IP, etc.", and no one mentioned any historical context around the choices.
The OSI model is a guide, not a law.
> It is important to distinguish "streams" (Dennis Ritchie's term for his revised non-block-device i/o system) from "STREAMS" (what AT&T put into System V). Dennis's streams cleaned up a lot of mess, and improved performance to boot. But as Dennis is rumored to have said, "`streams' means something different when shouted".