cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: forced caching of volatile data
Date Wed, 27 Aug 2003 11:56:31 GMT
Miles Elam wrote:
> 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.

This is definitely an interesting idea, but I can't believe that this 
sort of backwards-incompatibility would fly.  One option would be to put 
a null validity implementation in the Abstract* so subclasses don't have 
to do anything, but I can't see that happening in a 2.1 branch now that 
it's released.

> 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."

Yes, secure and sensitive data (which I'm working with now) often has 
the recommendation (sometimes requirement) to disallow caching.

The other centers around performance, which may not be an issue if done 
right.  Stefano's recent RT on adaptive caching is getting at the 
cost/benefit analysis of caching overhead.  Currently we do have some 
overhead - we do some instanceof's to determine cacheability.  If done 
right, your idea wouldn't necessarily be worse but it might be.

> 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?

Another problem I see with this is it locks into a time-based (expires) 
cache validity.  That is certainly the simplest but not always best.  As 
I see it, there are three main classes of cache-invalidation all of 
which Cocoon should support, and all of which may make sense for any 
given component:

- Time based (expires)
- Source based (last-modified)
- Event based (discrete events)

That's why I think the factory/delegate solution cooked up by Unico 
might be a good solution if the end-user experience can be made 


View raw message