Re: forced caching of volatile data

[Miles Elam]

Okay, here's a wonky thought: why not make all components cacheable?

...well  ...sort of...

What percentage of content is cacheable right now?  Perhaps a better 
question would be what percentage would everyone like to be cacheable 
right now?  In a perfect world, almost everything would be cacheable and 
allow simple cache expiration.  There are certain things that we want to 
be up to the moment, but by and large, the reason for this is that the 
highly dynamic data is not accurately cacheable (cache doesn't expire 
fast enough or the trigger for expiration isn't available).  Even pages 
that have the current time (assuming only year, month, day, hour and 
minute displayed -- no nanoseconds et al.) can have a minute-level cache.

Currently, one must implement CacheableProcessingComponent and write 
getKey and getValidity methods to cache a resource.  What if all 
PipelineComponents were CacheableProcessingComponents?   The default 
behavior of getKey would be to serialize the parameters and the value of 
"src".  The default behavior of getValidity would be to return null.

During pipeline processing, instead of checking if the pipeline 
components are instanceof CacheableProcessingComponent, it simply grabs 
the key and the validity.  If the validity is null and the pipeline 
doesn't have an expiry set, it is uncacheable just as before with only 
the time taken for key generation lost.  If the validity is null and the 
pipeline has an expiry, a no-op validity object is created for the 
component, and the CachedResponse object is created as is normal.

I know.  I know.  My pet project is warping my brain and making me see 
through glasses polarized to see the problems at hand.

Nevertheless, if expiries can determine cacheability, then *everything* 
is indeed potentially cacheable.  Any XSPs could be invoked only once an 
hour or once a minute from the sitemap where most other configurations 
happen anyway.  The cacheable XSP document in samples would become obsolete.

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

So am I off my rocker for proposing this?

- Miles Elam