cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: Cache
Date Tue, 25 Jan 2000 04:35:16 GMT
On Mon, 24 Jan 2000, Pierpaolo Fumagalli wrote:

> Andy Lewis wrote:
> > 
> > I would not only like to see something accommodate that case, but go further
> > if possible, and even one of the resources used to produce the page have
> > change, avoid re-processing those that haven't changed. I realize that at
> > some point there are diminishing returns, but so far I've seen VERY
> > expensive processing at every step for many requests, so my gut feel says it
> > would be worth it.
> 
> We thought also about having an MD5 representation of the HTTP request,
> and see if that one was equal to the previously received one (if a
> person enters the same data in a form, the page doesn't need to be
> regenerated)...
> That's an interesting point of view... I don't know if it's possible, or
> even if it takes less time to evaluate the cache rather than
> regenerating the site... It definitely needs further discussion...

More specifically, we were talking about caching fully generated pages in
a table keyed on the _relevant_ bits of the HTTP request. Cookies are
relevant for some requests, but not others. Querystring is relevant for
some requests, but not others. We've had the difficulty so far in
determining, given an HTTP request, which chunks are relevant. However, if
we could examine the 'special' namespaces will invoked by XSP pages (e.g.
http://www.apache.org/1999/XSP/Cookie), we can assume that the chunks not
referenced (e.g. http://www.apache.org/1999/XSP/Session) are not relevant
to the current URL.

Still leaves the problem of knowing if browser type were relevant, for
instance, and some other outstanding issues maybe. We could address them
in the sitemap probably.

I think we're ready to take this step here, at least for XSP pages.
Non-XSP pages can be assumed to be either keyed off of just the path part
of the URL (for pages that just use XSLT) or should not be cached (for
pages that use special processors).

Finally, I concur with those that contend that we need both a top-level
cache, which stored pages based on URL information, but we also need
caches for expensive resource internally (e.g. stylesheet object keyed on
resource url). I (and others I'm sure) reference big XML and big XSLT
files all over my sites (that is to say, the same big XSLT file from many
different XML files or, more generally, from many different URIs). It sure
doesn't make sense to perform the stylesheet object construction operation
more than you have to (at least, that was the case with XSL:P).

- donald


Mime
View raw message