Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F4CF428.3080408@pcextremist.com>
Date: Wed, 27 Aug 2003 11:10:48 -0700
From: Miles Elam <miles@pcextremist.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.5b) Gecko/20030808 Thunderbird/0.2a
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: forced caching of volatile data
References: <20030811012530.373a7bfa.ruf10@op.pl>
 <3F373A3B.5885.177883E@localhost> <3F3737B6.6090108@pcextremist.com>
 <3F37921D.2060406@leverageweb.com> <3F3816B4.2020909@pcextremist.com>
 <3F38A248.5010607@apache.org> <3F3A870B.5020202@pcextremist.com>
 <3F43B68C.8010301@apache.org> <3F43C654.1080308@leverageweb.com>
 <3F43E5F4.5010808@apache.org> <3F4C133C.1050200@leverageweb.com>
 <3F4C6A8D.9050005@pcextremist.com> <3F4C9C6F.1060107@leverageweb.com>
In-Reply-To: <3F4C9C6F.1060107@leverageweb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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