Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F4C6A8D.9050005@pcextremist.com>
Date: Wed, 27 Aug 2003 01:23:41 -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>
In-Reply-To: <3F4C133C.1050200@leverageweb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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."

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?

- Miles Elam