Re: [9fans] RPC-esque system calls?

[erik quanstrom <quanstro@coraid.com>]

> 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 anne@computer_one:/dev/microphone > anne@computer_two:/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