From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 20 Nov 2008 22:28:10 +0000 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <41C06C24DB13F7699EA324C7@[192.168.1.2]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 4cde66c8-ead4-11e9-9d60-3106f5b1d025 > That is, the concept of 9P and filesystesms thereof, is an idea of > `networking' in a very general sense In what very general sense? File servers and 9P seem to me to be mostly ideas about abstracting a computing platform's functionality, aka resources--I'm thinking udev or Windows HAL. The networking part only gains significance when one thinks, "hey, 9P is all text, and it's atomized, and it relies on no magical awareness, and it looks just like the interactions in a client-server model." Then one decides to put 9P in a, say, TCP connection and create a network-transparent environment augmented by 9P in two ways: 1. by making all applications use a consistent method of accessing resources 2. by providing a network-friendly manner of doing (1) Of course, the actual design of 9P must have taken place in the opposite direction. That is, (1) and (2) required the creation of 9P in the first place. -------------------------------------------------------------------------------- > whereas, the "networking" provided by /net, is an application of 9P, and > completely distinct from the 9P concept! True, but how does that negate the paragraph you have quoted? Do read the last section of this email to see in what sense I am agreeing with you and in what sense I am not. -------------------------------------------------------------------------------- > from the 9P concept! Now, to say, essentially, that "9P is networking > whose application, /net, is itself networking, and so to fondle with > this application is to fondle with the fundamentals of Plan 9, which > is contradictory to Plan 9 methodology", is absurd (I hope I've > properly paraphrased your statement above)! You have wrongly paraphrased me, and it is rather obvious why. Statement 1: 9P in the capacity of providing network transparency is an application of networking. (strictly true) Statement 2: Applications of networking, i.e. things other than "network glue," ought to occur at application layer. (strictly true) Statement 3: Statement 1 + Statement 2 + rules of inference = 9P must live in application layer (and it does). (Before you hit back, these assume networking, or rather internetworking, means packet-switched networking as it is prevalent on this planet at this time). -------------------------------------------------------------------------------- > The /net FS is directly an application of 9P, and to add further > functionality, such as packet analysis (which seems to be the new hot > topic now), is only to go so far as to change the /net "application" That's wrong (or maybe I'm wrong). Whatever "network glue" /net uses to get the host represented on the network lies _entirely_ outside of 9P's domain. It is conceivable that in an ideal world everything in /net, below the application layer 9P, is moved to and works just fine on any other platform with a C compiler. Is that an application of 9P _without_ 9P? Perhaps it will serve educational purposes to point out that _you_ have created a perfect vicious circle common with some 9fans. I have said this before and I say it again: abstraction doesn't do work for you. If /net talks 9P to layers of abstraction _beneath_ it, and 9P is the language your programs use to talk to /net, then who does the modest work of fetching the frames from your NIC, putting them in order, sprinkling your messages with network layer awareness, "the real thing," and all? Note that these are _not_ 9P-talk. Erik Quanstrom has put this in 9speak in his response to your posting. Please check it out. --On Thursday, November 20, 2008 10:30 AM -0800 akumar@sounine.nanosouffle.net wrote: > > While debunking these statements has been somewhat efficient thus far, > I think something has not been explicitly addressed -- >> The boasted transparency of Plan 9 is a product of bringing most >> (or really all?) functions, including networking, into a single >> framework. That single framework exists as an application of >> networking, i.e. 9P, hence living in the application >> layer. Descending to network layer is expulsion from the Plan 9 Eden. > > This seems to be the premise of the _current_ discussion. And the > problem here is that `networking', which ought to apply here as a name > for two distinct ideas, is confused as a name for the same thing. > That is, the concept of 9P and filesystesms thereof, is an idea of > `networking' in a very general sense -- whereas, the "networking" > provided by /net, is an application of 9P, and completely distinct > from the 9P concept! Now, to say, essentially, that "9P is networking > whose application, /net, is itself networking, and so to fondle with > this application is to fondle with the fundamentals of Plan 9, which > is contradictory to Plan 9 methodology", is absurd (I hope I've > properly paraphrased your statement above)! > > The /net FS is directly an application of 9P, and to add further > functionality, such as packet analysis (which seems to be the new hot > topic now), is only to go so far as to change the /net "application" > -- if, for example, an application on top of /net cannot be made to > handle this task -- and this is not, in any sense, fundamentally > conradictory to the (abstraction) layer at which one ought to work, in > Plan 9 (since, again, we're just working atop 9P). > Your further points -- aside from the misconception of NAT and packet > analysis and what not -- seem to be fueled by this intuition, so > hopefully this clears something up (or at least gives you new material > to "debate"). > > > Regards > >