Re: Suggestion: ALTHREF attribute

James Green (jmkgre@essex.ac.uk)
Sat, 17 Jan 1998 22:06:27 +0000 (GMT) 

From: James Green <jmkgre@essex.ac.uk>
To: www-html@w3.org
In-Reply-To: <s4bf64e3.010@smtpgtwy.ausd.k12.ca.us>
Message-Id: <SIMEON.9801172227.D@s1671.essex.ac.uk>
Date: Sat, 17 Jan 1998 22:06:27 +0000 (GMT)
Subject: Re: Suggestion: ALTHREF attribute


On Fri, 16 Jan 1998 13:46:39 -0800 Alex Fabrikant 
<afabrikant@smtpgtwy.ausd.k12.ca.us> wrote:

> <SNIP>
> If you think about this closely, it does sound as if a new META element 
> is being thought of:
> 
>    <META NAME="MIRROR" HREF="http://www.mymirror.com">
> 
> If this was in a page originating in the .co.uk domain, which was slow, 
> and being viewed in american .com domain, the browser could quite 
> easily give an option to change. Further mirrors could be included:
> 
>    <META NAME="MIRROR" HREF="http://www.mymirror.com" 
> HREF2="http://www.mymirror.com.au" HREF3="http://www.mymirror.com.tw">
> 
> You get the general idea.
> 
> The only problem it does not solve is if the source document itself 
> cannot be retrieved for some reason or another. That could be up to a 
> supplementary HTTP server redirecting requests to an appropriate 
> mirror, but that's for the hardware guys to work on, not me.
> </SNIP>
> 
> I don't quite see why this should be handled by the HTTP server. An 
> ALTHREF (or whatever you want to call it) should accept a 
> comma(?)-delimetered list of URIs, with a single function - providing 
> the client with an alternative address to load in CASE OF AN ERROR. A 
> META or a LINK-based system can be implemented as well, allowing for 
> definition of mirror sites, but this would not relate to the same 
> problem

I'm not suggestion the ALTHREF - or MIRROR - tag shouldn't be included; 
this is under the condition that the client can get the document _in 
the first place_.

What I actually said was both a suggestion of a META element (it would 
be in the upper-most section of the page so so have the highest chance 
of being downloaded, afterall) and for a secondary mechanism in case 
the HTTP server could deliver a single sausage of information; which of 
course is reliant on the secondary workings *not* relying on the http 
server!!!



Regards,

James Green

Term e-mail: jmkgre@essex.ac.uk   |   Home e-mail: jg@cyberstorm.demon.co.uk
Homepage: http://www.cyberstorm.demon.co.uk