cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Carvalho <scarva...@criticalsoftware.com>
Subject Re: [C2]: Proposal for caching
Date Tue, 23 Jan 2001 17:08:13 GMT
On Tue, 23 Jan 2001 17:21:02 +0100
"Carsten Ziegeler" <cziegeler@sundn.de> wrote:
 
> OK, lets start:
> 
> 1. Caching should not take place after each stage in the pipeline.
+1. 

Caching should take place at the end of every simple pipeline. Content aggregation causes
the aggregation of several simple pipelines, and each of these must have a separate cache,
or else the invalidation of one of these invalidates all the others -- Not Good(TM)

> 2. The most static part of the pipeline should be cached.
?!? The end result should be cached. 

> 3. The logic for caching is either in the ResourcePipeline or "above"
The logic that decides if the result has changed should be on the producer(s) and should be
overridable.

> 4. If a component is cacheable it should implement an interface Cacheable.
> 5. Caching is done until the first component in the pipeline is not Cacheable.
Rephrasing: Caching is done if every component in the pipeline is Cacheable. Remember, no
caching on each stage.

> 6. Identifying if the cache contains the response (or the most static part
>    of it) can be done by a unique key. The Cacheable interface implements
>    a getKey() method. The keys of all Cacheable components are chained together
>    and build the unique key for the cache.
-1. If Stuart is right, and transformers' output depends only on their input, then you just
need to check the inputs, and you just need to cache the final output.

> 7. Cacheable also delivers a Validator object (getValidator()) which contains all
>    information required for this component to test if the content has changed
>    since the last caching.
>    The FileGenerator e.g. puts the last modification date into the Validator.
>    The Cache stores all Validators together with the unique key.
+1. I'd like to see a setValidator also, so that the Validator can be overriden.


> 8. All Cacheable components are now asked hasChanged(Validator). If all
>    respond with false, the cache value is valid and is used. 
>    If the first responds with true, a new response is generated, the validators >
   are get and the result is put in the cache.

-1. See 6. Only the inputs (generators) must be checked.

> 
> This approach is very flexible. Each component nows if it is cacheable and when
> it is invalid. Using the Validator object it is possible to specify something 
> like: This component is really 6 hours valid wether it changes or not.

Please, allow the Validator to be overriden. I'm imagining situations like an HTTPGenerator
where the Generator doesn't know if it is valid and can only safely assume it is not. In these
cases, there are situations where I'd like to override this default behaviour.



--
Sergio Carvalho
---------------
scarvalho@criticalsoftware.com

If at first you don't succeed, skydiving is not for you

Mime
View raw message