cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: forced caching of volatile data
Date Wed, 27 Aug 2003 08:23:41 GMT
Gianugo Rabellino wrote:

 > Miles Elam wrote:
 >> If the Abstracts (AbstractGenerator, AbstractTransformer, etc.) were
 >> updated to reflect this, most folks using Cocoon would only have to 
do a
 >> recompile. Folks who implemented the interfaces directly (Generator,
 >> Transformer, etc.) would have more to do, but a cut and paste from the
 >> appropriate Abstract would do in 90% of the cases I should think.
 >> (Assuming that the developer hasn't made their component cacheable
 >> already.)
 > I can't really think of a reason for this not to work. The only problem
 > is that doing so would somehow break a contract: today if you extend
 > Abstract* you know that your class wont be cacheable, and this might be
 > done on purpose. I don't know if this might actually impact users, but I
 > sure can see a point here.

Hmmm...  Actually, the extended class would still be uncacheable on its 
own.  The change makes a system-wide policy change rather than a 
per-interface contract renegotiation.

Can anyone think of a use case where prevention of caching (not just 
apathy about its cacheability) would be necessary?  Is there a case 
where a developer would say, "I don't care what the sitemap maintainer 
says;  My component must never be cached or exceptions will fly."

By itself, the component still doesn't cache even when in a caching 
pipeline.  Only when the expiry is sent is the pipeline bludgeoned into 
the cache.  Would this still be considered a violation of the contract?

- Miles Elam

View raw message