Subject: PaceCaching

From: Walter Underwood <[email-masked]>
Date: Fri, 20 May 2005 13:55:14 -0700

--On Tuesday, May 17, 2005 09:13:37 PM -0700 Tim Bray <[email-masked]> wrote:
> PaceCaching
> Multiple -1's, it fails.

I'll address the objections anyway, because I (still) think this is important.

1. This introduces multiple caching schemes.

Wrong. Right now we have multiple schemes, with HTTP caching, ad hoc client
caching, and ad hoc server-side load shedding. This recommends one consistant
scheme, which we know will work. The current multi-scheme approach is a mess,
and we can be sure that it will have problems.

2. This applies protocol caching to a client.

True, but not really an isssue. HTTP caching does work when used to manage
a client cache. Compare a client working through an HTTP cache to one which
checks the cache information internally before issuing HTTP requests. The HTTP
server will see the same series of requests. Effectively, the client will
run a virtual HTTP cache internally.

3. Server-side parsing is too much overhead.

Maybe with 90 MHz Pentiums, but XML parsing is really fast these days.
Parse the file, cache the values, and toss them if the file has changed
when you stat it. Or, the blog server software can set the cache info
out-of-band to the server.

4. This requires synchronized clocks.

Those are a SHOULD for HTTP, too. And they ought to be a SHOULD for Atom
anwyay, because you cannot date-sort entries from two servers with
unsynchronized clocks.

5. This is just like HTTP-EQUIV and that has failed.

Yes and no. Most HTTP servers ignore HTTP-EQUIV, but it is still useful
for passing through things like content-language when there is no HTTP
header present.

For Atom, the caching info would be valid when there is no HTTP cache
header. This is exactly where HTTP-EQUIV is effective today.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek