[rik@daneel.rdt.monash.edu.au: Re: hangs/multiple servers ]
Marc Andreessen (marca@ncsa.uiuc.edu)
Thu, 19 Nov 92 13:54:21 -0800
Date: Thu, 19 Nov 92 13:54:21 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211192154.AA10782@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: rik@daneel.rdt.monash.edu.au
Subject: [rik@daneel.rdt.monash.edu.au: Re: hangs/multiple servers ]
In-Reply-To: <9211192142.AA10729@wintermute.ncsa.uiuc.edu>
> 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.
I think this is a good idea -- the really important capability it
enables is this: if I (I == ``real user using WWW mechanisms for real
work'') set up an HTTP server that people at my site will need to get
to at all times, then with this mechanism I could *at the very least*
tell my WWW clients about alternate servers that I also set up.
A big advantage is that nothing major (i.e., HTTP or HTML) would have
to be changed.
As for the problems: (1) it is true that to be useful in the general
sense a master list would have to be maintained, but each local site
would only have to pull down a new one every few months -- these
things aren't going to change that often (expansion is more likely),
and (2) is a problem with any change of anything at this point, which
is why I think a very lightweight change (like this) would be best.
Marc
--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu