Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: CachingProcessingPipeline: new Expires code
Date: Tue, 25 Feb 2003 12:51:38 +0100
Message-ID: <LKENJPKDAIKAPKHEOCMMIELGCMAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3E5A4361.10801@apache.org>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"


> -----Original Message-----
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
> Sent: Monday, February 24, 2003 5:08 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: CachingProcessingPipeline: new Expires code
> 
> 
> Carsten Ziegeler wrote:
> 
> > I would say: commit it and we (I?) can review it.
> 
> Done. Fire at will. :-)
> 
> Two things to consider and still on my TODO:
> 
> 1. I understand from AbstractCachingProcessingPipeline that a cache 
> entry is not going to be built if the generator is not cacheable. Also, 
> the cache process stops at the first non cachable component in the 
> pipeline. If that is the case (and indeed it makes sense)

Yes, exactly, this is the way it works.

>, then some 
> more changes are needed to take into account that an expires header is 
> present: if so, there should be a way to both generate the key and cache 
> the output and to update/remove entries from the cache if the expires 
> header is changed or removed from the pipeline. What would be the best 
> way to do that? I'm thinking about having an object that generates key 
> on behalf of non cachable components, would that be enough?
Hmm, I haven't looked yet into your code. What happens now if an expires
date is set, but the pipeline does not have a cacheable generator?

Carsten