Yes... it certainly would.
First of all, the final solution seems to be to use a globally distributed
replicated name server for documents or servers. Like x500 which isn't here
yet. The name service would return multiple pointers. The client could chose
intelligently which to try first. But we don't have that infrastructure yet.
In the mean time, the question is where to put the information.
In teh new HTTP protocol there are a number of objects which can be
returned ateth protocol level (rather than the data level) which include
error objects and forwards. A forward can contain multiple pointers.
However, it doesn't help reliability much because the server which hold the
forwarding info will be just as unreliable!
So one considers putting the multiple URLs (addresses) into the link in the
document. This smells too, because the positions of servers for different
parts of the abstract document space will be constantly evolving, and so the
links will be soon out of date, and that is grim for documents which may last
20 years...
The next solution Rik just mentioned:
> One possible way to implement backups is to have the client do it (makes
> the client too clever?). The client could have a list of hosts, and for
> each one, have a list of backup servers, to try if the main server is
> down. The problem with this is that the list is much more difficult
> to maintain, if everyone needs a copy, and only the clients that have
> implemented this would benefit.
But it is a simple stopgap. The way I would see doing it
in practice would be to call the name translation rule module (HTRules.c)
from the client as currently from the daemon httpd. The rules would
be extended to include a "try" operator, like "map" but
allowing continues processing of the rule file if the access failed.
This would be useful in the server too... for example to pick up date from some
remote mounted disk which is the original, but if that fails to use a cached
copy updated last night.
Tim