> First of all, we need a means to identify resources, both local ones and
> remote ones.
> The (ssh-like) URI idea seems to be good enough for it.
>
> cat [EMAIL PROTECTED]:/dev/microphone > [EMAIL PROTECTED]:/dev/speakers
>
> Ok... it's very naive, I admit; but it's just an example.
plan 9 can already do this
import computer_one /dev /n/dev1
import computer_two /dev /n/dev2
cat /n/dev1/microphone>/n/dev2/speakers
>
> What else do we need?
> 1) A common interface to devices and files (like Plan 9)
it seems you already know 9p can do this.
> The common protocol... well Plan 9 uses 9P, which is very nice, but I have
> a different approach.
>
> I'd encapsulate messages into SOAP (XML) envelopes.
>
> This has one big advantage and one big disadvantage.
> Advantage: it has no endianness problems, because it's just text in some
> encoding.
> Disadvantage: it is horrendously inefficient.
i see no advantage as 9p does not have an endian problem.
> However it has also got other nice aspects:
> - it's easy to create new messages: the whole infrastructure is there, you
> just have to generate some XML.
> - [I believe] it is a simple concept to understand
> - [I believe] it is simple to debug (messages are easily interpretable)
9p has these properties.
> Then, the operating system analyzes the message, and it decided whether
> it's a local or a remote operation.
> If it's a local one, it just carries it out and it sends an XML message
> back to the user process, and the C library will just decode it and return
> a value to the user in the standard way.
> Basically... the user doesn't know what's going on under the C API, it's
> transparent (as much as possible).
>
> If it isn't a local operation, the kernel acts as a proxy and forwards the
> request to the target host, which in turn will realize it's a proxy
> operation and it will return values back to the caller.
this sounds like a vague discription of a process' mount table.
>
> The key concept is:
> what you can do locally you can also do remotely.
>
> ...by virtue of making it the *single* way to access the kernel.
> So you can't say: "this is going to be implemented for the local interface
> only... we'll take care of the remote one afterwards", no way.
perhaps some of the papers here (http://plan9.bell-labs.com/sys/doc/)
would be helpful. i'd start with _the organization of networks in plan 9_.
- erik
