cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Ulrich Niedermann <niederm...@isd.uni-stuttgart.de>
Subject Re: Is Cocoon2 caching implemented?
Date Fri, 11 Aug 2000 15:27:33 GMT
Hi all,

just some more or less random thoughts about caching. 

Disclaimer: I still have to think this through completely and this
also probably affects the Sitemap -> Pipeline code rendering. I don't
know much about the Sitemap, Pipelines and Caching. 

"Stevenson, Chris (SSABSA)" <chris@ssabsa.sa.gov.au> writes:

[ XSLT-specific caching internals/proposals deleted ]

> What about adding behaviours like
> 
> getLastModified()
> getWhenExpires()
> 
> to each pipeline component, that returns a null by 
> default, then have the sitemap work out max() 
> by calling each in turn?

Sounds good to me. I've thought about caching during the last few
weeks (without having a look into existing caching code) and came up
with a similar method but that didn't go that far.

However, the getLastModified() and getWhenExpires() methods probably
have to know about request parameters (URI params, Post stuff,
cookies, sessions etc.) to determine if the output data has changed.

> This makes more sense to me because the idea of
> modification time belongs on the component 
> (be it generator, filter or serializer) and 
> not at the sitemap level...
>
> For example, suppose there is a filter that uses 
> some time-based criteria to change the way it 
> generates a file (maybe black bg for evening,
> yellow for daytime). No files change, but the 
> last-modified *does* change.
> 
> This could also be used to abstract out the 
> re-compilation and caching tests - you just call 
> getLastModified() on each pipeline component, 
> and if it is later than the cached version, 
> mark the pipeline as dirty. 

And this even lets us write a cache engine that caches intermediate
data, i.e. the possibly expensive first parts of the pipeline that
depend only on seldomly changed data are only seldomly called. 

But this suggests adding a third method to all pipeline components
that tells the cache engine if caching results makes any sense at all
(imagine a component that outputs the current time).

> This is also more general than the current 
> hasChanged() on sitemap..
> 
> again for example, suppose there are two or more
> caches reading from the same sitemap object,
> maybe on a distributed system... calling 
> hasChanged on the sitemap will cause inconsistent 
> behaviour, since the first call will reset to false,
> and the next cache to call hasChanged() will think 
> nothing has changed.
> 
> this would mean a change to the interface of 
> SitemapModelComponent and SitemapOutputComponent.

Uli

Mime
View raw message