Re: 9grid advocacy, etc.

Hmm.  previous post suffered from phoneticism...(a neologism?)
I obviously meant to say "Tao of 9"...
I think on reflection, this title would be worthy of something other 
than what I offer.
However, here is the general flow of my 5 minute pitch of the 9way.
Its not ultra compact, its not witty (and I hope its not too wrong!)

Please beat up on it.   (sorry, refactor)

Leo

A short pitch on the 9way.

The file has a clear definition in computing:  people generally agree 
on what a file is and how one can operate on it:  read, write, create, 
delete, stat,  etc

The file is the central metaphor underlying the Unix system:   
"everything is a file", but all files are not equal.  The system 
devices appear as files, but have specialised semantics.  Until 
recently, processes etc, did not have file system representations.

Arranging files in a hierarchical file system is a powerful and 
intuitive representation for the organisation and navigation of system 
resources.

File systems can be exported between systems.  However, if not all 
resources are represented as files, not all resources can be exported. 
For example, because of the "special" files in Unix, exporting devices 
between systems is not straightforward

Plan 9 represents all system resources as files.   This metaphor is 
applied rigorously and uniformly.  System data files, devices, 
processes (as well as network interfaces, for example) are all mounted 
in a hierarchical file system, known as a "namespace".

The uniform representation of system resources is made possible by a 
file system protocol known as 9P.  9P encapsulates all necessary file 
system operations in a simple, compact protocol.  The file system 
operations are transported between systems using 9P messages, and 
executed locally via system calls.

9P is the heart (and soul) of plan 9.   The plan 9 operating system 
kernel can be regarded as a 9P multiplexer.

In plan 9, an application can represent its interface as entries in the 
namespace.  For example, /prog/app might accept its arguments through a 
write to a file /prog/app/cmd and provide output data via a read from 
/prog/app/data.

Thus all system resources and services can be made available in the 
namespace and can be exported to remote systems.

As all system resources and services are represented as files, and 
these files can be exported, then inter-process communication (IPC) and 
remote procedure calls (RPC) can be achieved simply by writing to and 
reading from files in the namespace.     The 9P protocol can thus be 
regarded as the last word in file system and IPC protocols.

A very important feature of plan 9 is the ability to manipulate the 
namespace.   (Remote) file systems can be mounted, and bound to 
arbitrary points in the namespace. (No more fixed mount points, 
environment variables, symbolic links, etc).     Furthermore, 
namespaces can be constructed dynamically on a per-process basis.

It is the namespace operations that confer the great control of 
resources in a distributed system.    A process can construct its own 
view of the world, "mounting" devices and services and "binding" them 
into specific places in its namespace.  Thus services can be made 
(un)available to processes through export controls on file systems and 
the use of file permissions.

It is the representation of arbitrary system resources or services 
(local or remote) as files in a tailored hierarchical namespace which 
significantly lowers the barrier to distributed computing.