Re: Ordered 'opqque' validators

> Another thing I would really like to know, to what extent we can
> expect hierarchical caching to be effective ?

It is already effective in New Zealand and at least two European
countries.

> We know that there are some very popular servers on the internet,
> so that caching traffic to these servers might look effective. But
> the objects are single files/documents. What percentage of the
> millions of files of these servers gets really accessed let's say
> 10 or more times (within a reasonable time frame, say 1 week .. 1
> month), so that caching really turns out to be a significant saving ?

Like many things, it depends on the nature and size of the user base
and the breadth of subject area being accessed.  In practice, all
caches are effective -- if they were not, they wouldn't be used.

> And, especially, how many of these files get accessed just once,
> so that no caching policy is going to help ? I suspect getting
> these info from some very large server would really help in
> determining what we could expect from our cache, the depth of the
> hierarchy, etc.

I'm sure it would.  However, those concerns are irrelevant to our task.
HTTP is an enabling protocol -- my job as the primary designer of HTTP/1.1
for the W3C has been to identify areas where HTTP lacks extensibility or
completeness and fix it.  I don't care where the fix comes from, so long
as it is a "true" fix (i.e., is true to the spirit and design of the
HTTP/1.x protocol) and is extensible to the scope of the problem space.

We have already established that at least one person desires a
multi-layered caching mechanism and has already implemented it.
We have also established that some content providers are not happy
about the way some caches choose what and how long to cache.

What we need is an HTTP standard that defines the proper way to do
caching and includes the mechanisms needed to communicate caching
requirements.  So, I designed a mechanism to do that and presented it
to the working group last summer, got a bunch of comments, and
produced an updated version in the HTTP/1.1 specification.  The purpose
of the subgroup is to probe that specification for holes and
propose wording to fix those holes.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 7 February 1996 02:07:22 UTC