From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199402190334.AA29777@oit.gatech.edu>
Subject: Re: caching
To: atotic@ncsa.uiuc.edu (Alexsander Totic)
Date: Fri, 18 Feb 94 22:34:32 EST
In-Reply-To: <9402190231.AA26019@void.ncsa.uiuc.edu>; from "Alexsander Totic" at Feb 18, 94 8:31 pm
Alexsander Totic said this:
> Michael.Mealling@oit.gatech.edu writes:
> > I'm thinking more and more that URN->URL resolving should be
> > URN->URC resolving...
>
> Depending upon the purpose of the query. If we are looking for speedy
> resolution, where the browser automatically picks up the best solution
> (WWW browsing scenario), the only really important thing that browser
> needs to know is where the closest node is. If the user is not pleased with
> the result, he can look up the URC, and get more info. I think that overhead
> associated with retreiving a list of URCs for every query would be significant.
> Also, in a list of URCs resulting from a resolution of a single URN, most of
> the information would be replicated, and usually only URL and type would vary.
Correct. I envision a method for restricting the amount and type of information
returned in a URC. That's one of the reasons I really like whois++ as a
URN->URC resolution scheme. It allows you to specify which fields you want
to see as opposed to all available. Therefore you could simply request a URC
with just the URL(s),TTL, and size fields intact. You get speed (depending
of course on the speed of the resolving server) plus you get more info
for your client to make decisions with (i.e.: User, that file is 5 Meg, do
you really want to get it? (y,n)).
-MM
-- ------------------------------------------------------------------------------ Michael Mealling ! Hypermedia WWW, WAIS, and gopher will be Georgia Institute of Technology ! here soon via MIME. Your view of the Michael.Mealling@oit.gatech.edu ! internet is about to change completely!