sundar@case.CSNET (Sundar Iyengar) (05/15/87)
Is it possible on Aegis to associate mutiple links with a name
arranged by some priority, so that the name is always resolved
to the highest prority object on the list, provided it is available?
If not, successively next ones on the list should be accessed.
For example, we would like a link called x to point to
//x1/a, //x2/a, //x3/a.... Every time x is referenced, it should
be resolved to //x1/a. However, if the node x1 is down or not accessible,
x should resolve to //x2/b, and so on. Similarly for links to
other objects.
Thanks.
Sundar R. Iyengar
ARPA: sundar%case.csnet CSNET: sundar@case
UUCP: {decvax,cbatt,cbosgd,sun}!cwruecmp!sundar
USNAIL: 531, Crawford, Case Western Reserve University
Cleveland, OH 44106paul@FLEETWOOD.CC.UMICH.EDU.UUCP (05/15/87)
It would be pretty hi-tech to have a function evaluated as part of a path name, in addition to the environment variable (or something else a little more flexible). Or, in some other fashion to have the value of environment vars change on the fly, as it were. The first time a path was resolved, the result of the evaluation could be cached, or what have you, and then have some magic that would tell when the cached entry was stale, and the link should be re-evaluated. Or something. --paul
krowitz@mit-kermit.UUCP.UUCP (05/16/87)
Actually, if you think about it, it's not all that hi-tech at all
considering what the Apollo file system does already. The extensible
streams functions allow the user to evaluate any sort of function that
he/she cares to write code for. It just takes the time for someone to
sit down a do it. One simply (simple if you're used to write new
object type managers) has to define a new type of link which tests
if the object pointed to is available, and if not, tries an alternate
object.
While I'm at it, does anyone know if Apollo teaches any courses on
writing type managers using the Open System Toolkit. I glanced through
the manual and it was less than crystal clear (at least for people who
aren't used to writing file systems).
-- David Krowitz
mit-erl!mit-kermit!krowitz@eddie.mit.edu
mit-erl!mit-kermit!krowitz@mit-eddie.arpa
krowitz@mit-mc.arpa
(in order of decreasing preference)freedman@calgary.UUCP (05/19/87)
In article <8705150741.AA00372@yale-eli.arpa>, sundar@case.CSNET (Sundar Iyengar) writes: > For example, we would like a link called x to point to > //x1/a, //x2/a, //x3/a.... Every time x is referenced, it should > be resolved to //x1/a. However, if the node x1 is down or not accessible, > x should resolve to //x2/b, and so on. Similarly for links to > other objects. Sounds like an ideal job for Apollo's Open System Toolkit to me. With this package, you can create new kinds of filesystem objects which behave in special ways. What you do is create a set of type manager routines which take care of accessing the object. Once this is done, you can access the object using standard language or system calls (open, close, etc), and your manager routines will take care of the rest. In your case, you would write the appropriate routines for opening the file according to your filename resolution scheme. You can inherit routines from existing filesystem types, so you won't have to write any of the routines for reading, writing, (etc) the files. Dan Freedman The University of Calgary Computer Science Department.