[rik@daneel.rdt.monash.edu.au: Re: hangs/multiple servers ]

marca@ncsa.uiuc.edu (Marc Andreessen)
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>
References: <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 Andreessen
Software Development Group
National Center for Supercomputing Applications