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 uncomplicated.
Geoff
