Re: Distributed VSTa

On Mon, Nov 30, 1998 at 01:52:19PM -0800, David Jeske wrote:
> 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.

Well I guess I should be more explicit. I was proposing backing off from the
use of //<path> to refer to namer space (which, as you say, invites hard-coded
dependencies) and using //<node>/<path> to refer to a networked object on
node <node>. However as you said, this is not easily virtualisable, but on the
other hand could be provided by a namer union mapped into /.

My reasoning behind this syntax is from a "user" point of view. When working
with DomainOS I found it just plain handy to be able to type

cat //kate/etc/passwd

and so on. I think that using the //<node> syntax is a very straightforward
way of accessing networked nodes. However it also imposes problems like
how the existence of such nodes gets registered with your system and so on.
(For DomainOS, you had to create an entry in '//' for every node you wanted
to be accessible).

One point I'm not sure I understand, just how the current pathname syntax
works. If I wanted to access the subdirectory tmp of fs/root, can I do this
now by opening //fs/root:tmp or must I explicity use mount?

> 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

That's basically what we've got now, unless I'm confusing '//' to mean
namer space vs. pathname space. I'm not sure I understand this distinction.

> 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.

Yes. Maybe to avoid problems (I'd like to use //<name> as well as //<ip>)
you could establish a convention to map this namer to /n so we get

/n/204.36.4.15/foo/bar
/n/kate/foo/bar

I'd like to see this consistent with the method to access namer space.

> 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.

So you want a completely 'flat' namespace?

In that case, do we want to keep //fs/root:tmp or just use //fs/root/tmp
instead? In which case you could do 'neat' stuff like creating a "virtual"
root and doing ln -s //fs/vfs/devel/vsta /vsta.

Ideas? Comments?

Martin
Received on Mon Nov 30 22:09:41 1998