[David Jeske <jeske@home.chat.net> writes:]
>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.
I feel like I'm quibbling semantics, but...
Isn't this the same as saying that you use "mount" to to bind the remote
object to its local name, and then all applications use the local name. Why
is it inherently superior to impose the level of indirection *before* the
mount command?
>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.
Ah, I see your point now. If we use /dev/mouse (be it a local device driver
found via namer, or a remote mounted via the net) then you have a point of
indirection, and thus could virtualize it (ala 8.5 windows). If we use
//dev/mouse, you don't, and can't (as it were).
The use of //<namer> is not too prevalent in SW--we could back away from
this technique. Its use mostly stems from resources which are used for one
single purpose, ever--it is both a conceptual and run-time burden to demand
that they always be a part of your pathname space, and yet requiring that
they be mounted before use created a--usually--unneeded extra step in
starting things like filesystems on top of disk drives.
OTOH, per-user overrides for namer node values wouldn't be too terribly
difficult to implement. We could likely steal some tricks from /env, which
also implements a somewhat different nature of per-user data values. We
could agree to press forward, and implement such a beast when a fully
self-virtualizing windowing system, or a related need, finally became
pressing.
Andy
Received on Mon Nov 30 11:17:11 1998
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:56 PDT