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.
That's what I was suggesting: that the default implementation returns a null validity. As far as missing the 2.1 branch, c'est la vie. As long as 2.2 (or whatever) doesn't take as long to be released as 2.1, I have no problem with that. ;-) I've been using CVS HEAD from time to time anyway, and I can always patch it myself if need be. I'm not trying to short-circuit the way development works. If people want it, they will come. If not, I'll either use it anyway with a patch or, more likely, use the implementation that someone thought up that does the job better. (Like perhaps your event cache?)
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.
I'd be shame that the sitemap maintainer and the component developer would have such lack of communication. Nevertheless, what about overriding getKey to return null to *enforce* a lack of caching. In other words, effort must be made to make sure that the component (and subsequent pipeline elements) cannot ever be cached. In other words, making the behavior as it is today.
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.
I was under the impression that the determination of cacheability wasn't anywhere near the overhead of actually caching (registering with the cache manager, putting the output in a CachedResponse object, etc.). But you're right, the only to tell for sure would be to implement it. I just wanted to make sure that people were at least slightly receptive to the idea.
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:
How so? There is nothing stopping a component from specifying its proper mode of caching like it done today. The time-based validity is only substituted when there is no other mode available (and expiry is requested). In fact, there is nothing (that I can see) that would bar other validity substitutions if the need arose. As it happens, without proper knowledge of the resource, only time-based expiration seems appropriate.
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 uncomplicated.
The more, the merrier.
- Miles Elam
