cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: forced caching of volatile data
Date Wed, 20 Aug 2003 21:19:48 GMT
Geoff Howard wrote:

> I apologize if I've already mentioned this, but I think there are some 
> different angles on solving your problem which you may want to consider.
> One is implemented in part in the event-cache block but it could be 
> generalized to work for any component.  Unico Hommes wrote a Generator 
> (in that block, but don't know its name) which uses a Delegation pattern 
> to wrap any other arbitrary Generator.  It delegates all interface 
> methods to the wrapped generator except for the get Validity (and 
> currently the key as well, but I think that might need to change.  He 
> then uses a factory which specifies how to construct the overridden 
> validity.  The plan was to generalize this to work with any component. 
> Hope that makes sense.

Interesting and worth a look, but I see a few problems:

1. Usability wise it might be uncomfortable for users to wrap every non 
cacheable sitemap component into a delegate (provided that users know 
what is cacheable and what is not);

2. There is no transformer yet (even if, agreed, it would be pretty easy 
to build one);

3. AFAIU, in order to use the delegate components, you should be using 
the EventAwareCacheImpl, am I wrong? This might be a serious showstopper.

The whole idea of this expires-enabled stuff is that of a simple 
solution for a simple scenario where the user knows in advance for how 
long a pipeline might be valid. A sitemap parameter, and you are ready 
to go, just as httpd's mod_expires does ... I'm not sure that the 
delegate solution is understandable by a non java programmer: it 
requires quite a bit of understanding of how the event cache works and a 
good knowledge of Cocoon internals, don't you think so?

> The second possibly simpler solution is to create a new pipeline 
> implementation that always caches.  So, when you have a pipeline that 
> should be forced to cache, you segregate it into its own map:pipeline 
> section with a parameter that speficies how long to cache.

Yes and no. We have been through this before, but again there is both a 
backward incompatibilty to consider (the current 
CachingProcessingPipeline supports Expires) and a fair amount of code 
duplication needed between the two implementations. But again, it's 
something to consider.

> A third is to consider the event based cache stuff itself.

Which looks really cool, and definitely it's something to work on, apart 
from the Expires stuff. How much do you still consider it alpha stuff?


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Now blogging at:

View raw message