I wonder how the "narrow waist pattern" differs from the general (very widely practiced) notion of information hiding / abstraction in computing more generally. I think most fields of computing tend to treat it as the key to controlling complexity, enabling modular decomposition and verification, and interoperability / interchangeability. Is there something different about the way it works in networking?
In general I agree with Graham's "OSI Deprogrammer" doc (as much of it as I've read so far) that teaching a simple "network-on-network" model (or "protocol that both carries payload for those above and is payload for those below") is better practice, and sorta relates to what I was asking above: it feels to me the core of his point is just to teach the general concept of an abstraction -- with things it assumes and things it provides given those assumptions are satisfied -- and that's a good enough concept on its own without dressing it up in references to OSI or unified 7-layer-burritos with separate globally-preordained functions. Seems right to me! I mean, we wouldn't teach general computer-system or program design with a predetermined numbered set of abstractions (unless we adopted 12-factor applications, ha!)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2024-03-27 17:30 (UTC)I wonder how the "narrow waist pattern" differs from the general (very widely practiced) notion of information hiding / abstraction in computing more generally. I think most fields of computing tend to treat it as the key to controlling complexity, enabling modular decomposition and verification, and interoperability / interchangeability. Is there something different about the way it works in networking?
In general I agree with Graham's "OSI Deprogrammer" doc (as much of it as I've read so far) that teaching a simple "network-on-network" model (or "protocol that both carries payload for those above and is payload for those below") is better practice, and sorta relates to what I was asking above: it feels to me the core of his point is just to teach the general concept of an abstraction -- with things it assumes and things it provides given those assumptions are satisfied -- and that's a good enough concept on its own without dressing it up in references to OSI or unified 7-layer-burritos with separate globally-preordained functions. Seems right to me! I mean, we wouldn't teach general computer-system or program design with a predetermined numbered set of abstractions (unless we adopted 12-factor applications, ha!)
Re: terminals, I think a lot about ARPANet getting started because Bob Taylor had to have 3 different terminals in his office to talk to 3 different remote computing sites. Of course the lower level protocols also had to be made to agree, but so did the terminals!