cocoon-dev mailing list archives

Geoff Howard wrote:
> 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