Re: Distributed VSTa

On Mon, Nov 30, 1998 at 02:45:42PM -0800, Andy Valencia wrote:
> I feel like I'm quibbling semantics, but...

Agreed, and I hate to feel that way, but I think it's a bit more than
that and I hope someone thinks there is some useful information in
here. This email finishes my point.

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

Exactly...

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

Exactly. The "//<namer path>:<path>" syntax making it's way into the
standard lib, and the recent discussion of incorporating some node/ip
naming syntax both put more emphasis on the namer as a vendor of
system resources. If namer is going to be a vendor of system
resources, then (IMO) it needs to be virtualizable (i.e. have a level
of indirection).

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

Certainly, but I think the question is 'do you want to?' In other
words, is VSTa (1) following Plan9/UNIX in putting system services
within the pathname space or (2) using the namer as a repository for
system services, from which the local pathspace (storage space) is
built.

Moving back to the 'proxy node naming' discussion:

If (1) then the qnx-esq node naming can be handled by mounting a 'node
redirector' into the pathname space. For example, union mount the
proxy resolver into "/" and allow "/@204.94.139.85/fs/root" to map to
the right place.

If (2) then the namer can provide the funcitonality, or you can mount
the functionality into the namer-namespace, but the namer needs to be
per-process.

In either case, I might consider it bad practice for someone to write
software which hard-coded node names or IP addresses into paths, but
either strategy allows me to redirect them.

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