🚀 go-pugleaf

    Managing network resources would be much easier, and the network
    more robust, if Aegis allowed symbolic links to have alternatives.

I think this would be a fine idea.  In fact, eons ago, when I was at
Yale, I implemented this feature in the naming server.  (I called the
feature "multilinks".) The change was never integrated into the standard
software.  Now that I'm at Apollo, and conveniently, since I happen to
do a lot of hacking on the naming server, I've been wanting to put this
feature in for real.  Unfortunately, other things have had higher priority.

Note that we'd really like to solve the underlying problem -- supporting
automatic switching among multiple copies of the same file -- in a more
sophisticated way.  We call this the "replicated object" problem and
a good solution would have tools for maintaining consistency and
broadcasting to find locations (rather than forcing every node to always
node about all the copies).  The proposed naming hack, is effective,
but crude.  But I'll probably do it anyway if I manage to find two free
days in a row.

There's an interesting question w.r.t. this feature though.  Note that
it could be implemented by using environment variables rather than links.
E.g.:

    $ ev := "//node1/sys/help,//node2/sys/help"
    $ catf "$(ev)/ld.hlp"

This implementation would have more in common with TOPS-20 (and I suppose
VAX/VMS) "logical names" (I think VMS calls them "symbols" or something)
in that the name is dynamic.  This is as opposed to the solution that
uses links, which is more static.  Consider two nodes booted off the
same disk:  With the link solution, both nodes (i.e. the users at both
nodes) are obliged to live with the same expansion, since it is in the
file system.  With the environment variable solution, each user can set
his environment variables to his own liking.  The disadvantage of the
environment variable solution is that it requires every user to have
those variables defined.  (With the link solution, a system administrator
can set up the links when he configures the node.)  The problem can be
lessened by defining the variables default values in the node's startup
files, but I suspect that will be "unreliable" and more work (from an
administrative point of view).

I'm afraid both implementations make sense (i.e. one could want both),
but I'm loathe to actually do both since it seems like it would cause
no end of confusion.  (I wouldn't want to have to write the documentation.)
I'd be interested in hearing people's comments.

            -- Nat Mishkin
               Apollo Computer Inc.
               apollo!mishkin
-------