Geoff Howard <[EMAIL PROTECTED]> writes: > > >> 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.
Hi Geoff, from what I understood I thought that Miles was proposing exactly that (default null validity)? > > 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. Well, since by default the data a component produces wouldn't actually make it's way into the cache (the components is cacheable, the data isn't), what's the impact? > 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. Again, no change to the impact on the cache. Just less Cocoon code: everything is considered for caching, no key or no validity, no caching. Same as today; but currently it's possible not to be even asked for a key or validity. Going forward you'd always be asked (or the abstract code would always be asked) but you could still decline to be cached. > > 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. Umm why? You can still invalidate the validity in any manner you see appropriate, or for that matter, you can still manage the cache of actual data in any way you see fit...
