Re: Distributed VSTa

This is going to strike deeper into some OS philosophy than just the
naming of proxied objects, but I think it's important stuff.

(IMO) Much of UNIX's management problems come from the inability to
easily 'vm' (i.e. virtual machine, i.e. fake, remap, etc) the runtime
environment. VSTa's process local pathname space (in the spirit of
plan9) improves this, but the namer is not VMable, so the more VSTa
relys on it, the more it falls into the same problems UNIX did.

On Mon, Nov 30, 1998 at 09:22:33PM +0100, Martin Lucina wrote:
> > By adding the "@<ipaddr>" suffix, this same request occurs, but out on the
>
> Cool. One thing that bothered me when you introduced the //<path>
> syntax for talking to the namer is that I would really like to see
> //203.96.5.14/tmp/<path> work, somewhat like DomainOS or QNX. Maybe
> `mount' isn't the right name for what we're doing, but we could use
> simply

Curious, I really dislike that approach. When you allow the pathname
space to become an add-hoc repository for information, you increase
the potential for hard-coded dependencies to end up buried everwhere
in the system. I'd prefer to force the namespace to exist in it's
purely symbolic form in the namer and mount code, and any magic of
mounting proxied objects into the local namespace to happen outside of
the mount path syntax.

For example, instead of your examples below:

> mount //203.96.5.14/tmp /dist
>
> or
>
> mount //203.96.5.14/fs/root:tmp /dist

I'd prefer it if there were a command to tell the proxy server to map
"//fs/root@204.96.5.14" to the local "//remote/fs/root" and then have
any use of the mount command refer to that proxied object by it's
local symbolic name "//remote/fs/root". This assures that if you want
to use scripts or environments which are dependent on that network
proxied object work elsewhere, you merely need to provide "//remote/*"
symbolically, not literally.

If there were to be a "//<ip>" syntax, I'd prefer to see it as a
product of a custom namer, so that <ip> was really just another
symbolic part of the namespace which this particular namer knew to map
to IP addresses, but which in another setup could be remapped to
something else.

=====

However, I don't think this increased focus on the namespace syntax is
a good direction. I assert that bindings between the system services
(in unix, files) and applications need to be (re)mappable.

UNIX didn't do a very good job of this, chroot() is seldom used and
dosn't work the way one would like.

Plan9 fixed this problem by having applications still focus on the
UNIX-like pathname space, but by allowing process local mounting into
this pathname space.

It's key that Plan9 programs still get the mouse from "/dev/mouse". If
VSTa programs start doing things like getting the mouse from
"//mouse", then we've gone back to the non-remappable unix model
again, and I think that's a step in the wrong direction.

If VSTa is to pull devices and services out of the 'pathname space'
proper (i.e. don't have devices be files in the pathname space like
Plan9 and UNIX), then IMO we should come up with a mechanism to allow
the namer mappings to be per-process.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske_at_chat.net