Re: forced caching of volatile data

[Miles Elam]

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