Norman - thanks - fair enough, but I stand by my original statement.

Greg, Dennis, Presetto, Sam and couple of others spent an evening discussing it all at USENIX one night; early before Dennis has finished the original implementation.    I'm very much sure, that while it was used for networking, the TTY handler and low speed I/O was the driver.

On Mon, Sep 25, 2017 at 1:57 PM, Norman Wilson <norman@oclsc.org> wrote:
Clem Cole:

  It was never designed for it.  dmr designed Streams to replace the
  tty handler.   I never understood  why the Summit guys insisted on
  forcing networking into it.

======

You've mistaken.
​Maybe -- its possible, but as I said, I certainly talked to Dennis and Greg about this at length.​  It was a hot topic a number of times.   Greg could get sort of animated ;-)


 
  The point of the stream I/O setup with
stackable line disciplines, rather than the old single
line-discipline switch, was specifically to support networking
as well as tty processing.

TTY, I 100% agree - this was exactly the problem that was trying to be solved. - being able to handle networking was a side effect.

​...


The problem Dennis wanted to solve was that tty handling
and network protocol handling interfered with one another;
you couldn't ask the kernel to do both, because there was
only one line discipline at a time. 
​This was an issue, but  don't think this was as important as... 
the desire for stackable so we could mix and match line disc​iplines period.


 
Hence the stackable
​ ​
modules.
​Right ...  that was a driver ....​

 
​...
 which
expected its own special `new tty' line discipline, so the
network code would have to know which tty driver to call.
It made more sense to stack the modules instead, so the tty
code was there only if it was needed, and different tty
drivers could exist without the network code knowing or caring.
​Exactly....​

 

When I arrived at the Labs in 1984, the streams code was in
use daily by most of us in 1127.  The terminals on our desks
were plugged into serial ports on Datakit (like what we call
a terminal server now). 
​Right... exactly what Greg and Dennis were trying to fix.​

How the top half of the tty handler had various needs and how to efficiently implement it.
Some tty handlers had become quite sophisticated... UCB's line discipline was just the start.

For instance, Steve Zimmerman did a version that was sort of combination of UCB, ITS and TENEX that Masscomp would pick up (which I sometimes miss).   IIRC the argument, Greg's position was that we should be able to create something that was user providable ultimately, that could make things as fancy or as plain as an application needed.   

Instead of doing stty/gtty calls to turn on cbreak or the like, an application like emac/vi or whatever could ask for a very simple path [Domain referred to the as 'borrowing' the path IIRC].   Other programs, say the ed and Bourne shell might want something fairly fancy under the covers.

The stacking scheme was so that we could easily define how chars would be handled and which layer would handle them.
The problem, as you point out, was the transitions between different 'modes' - which the original line discipline code had trouble with and stacking and unstacking only made worse.   But I digress.


 

Later there was a TCP/IP that used the stream mechanism. 
​Yup....   but was an afterthought .... look what I can do.
My point, it was a secondary effect... it was there and worked.
 


​....​

All this is very different from the socket(2) way of thinking,
and it has its vices, but it also has its virtues.

And yes, sockets had not (yet) completely taken over.
These were some of the experiments to see what would happen. 

Now, what caused it to fail as a networking interface?

Clem