On 18 Dec 2003, at 05:27, Sylvain Wallez wrote:
We're talking about validities, but before checking a validity, we first have to obtain it through the cache key.
In the current Cocoon architecture, keys of cache entries are built with abitrary data defined by each of the individual pipeline components. The result of this is that we can have several different cached responses for a single request definition (URI + headers).
Yes.
The big benefit of this approach is that many variations can be cached (depending on night/day, local weather, whatever), but the main disadvantage is that the pipeline *must* be built for every request in order to compute the cache key, even if the response is served from the cache afterwards.
Very true.
A solution would be to have another pipeline implementation that uses a different strategy to build cache keys. What comes to mind is that instead of returning abitrary values for key, components could return some matching criteria on request metadata. The pipeline could then organize the cache entries by URIs, each URI having a list of cached responses along with the matching criteria.
This approach would reduce the possible cached variations for a given request, but would allow to find cached content (and its validity) without incuring the cost of building the pipeline.
What do you think?
Hmmm, sounds very interestings, can you elaborate more on this?
-- Stefano.
