From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 30 Aug 2012 10:44:40 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <68ce90976b22bdb0929ccccafef4b7d0@kw.quanstro.net> <3330200.XJjoRb8JbZ@blitz> <5538fcd345a73fc294c6ee568f2fcdb4@kw.quanstro.net> <8ee568439e1855124564ecf0e83ac2b3@kw.quanstro.net> <6c7d84f203a2cc4f3427e177e34fa9d9@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b4e2d5da-ead7-11e9-9d60-3106f5b1d025 On Thu Aug 30 10:28:24 EDT 2012, crossd@gmail.com wrote: > > said another way, we already have typed streams, but they're not > > enforced by the operating system. > > Yes, but then every program that participates in one of these > computation networks has to have that type knowledge baked in. The > Plan 9/Unix model seems to preclude a general mechanism. that's what i thought when i first read the plan 9 papers. but it turns out, that it works out just fine for file servers, ssl, authentication, etc. why can't it work for another type of agreed protocol? obviously you'd need something along the lines of tlsclient/tlssrv if you wanted normal programs to do this, but it might be that just a subset of programs are really interested in participating. > > one can also use the thread library technique, using shared memory. > > Sure, but that doesn't do much for designing a new shell. :-) the shell itself could have channels, without the idea escaping into the wild. - erik