Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E5A4361.10801@apache.org>
Date: Mon, 24 Feb 2003 17:08:01 +0100
From: Gianugo Rabellino <gianugo@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: CachingProcessingPipeline: new Expires code
References: <LKENJPKDAIKAPKHEOCMMKEIKCMAA.cziegeler@s-und-n.de>
In-Reply-To: <LKENJPKDAIKAPKHEOCMMKEIKCMAA.cziegeler@s-und-n.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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), 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?

2. Some work needs to be done on the HTTP response abstraction. As of 
now it might well be that a component in the pipeline sets the HTTP 
Expires header in an arbitrary way, thus overriding the pipeline 
setting. This is a more general problem, it shows up with these 
modifications but it could happen with every pipeline: the value sent to 
the browser/cache would be the last one set in the pipeline. And it's 
not limited to the Expires header, actually: every component has access 
to the response object, so it's free to fsck up even the most carefully 
crafted pipeline. This is a real PITA, expecially if we are to continue 
on the path of proxy-friendly HTTP headers, where the resulting response 
should come from a very careful and thought out logic-

I'm thinking of the best way to intercept the setHeader() calls and put 
some logic in there in order to use the setting that makes more sense: 
under a "non expires" pipeline, it should be the minimum value, while if 
an "expires" setting is present, its value shouldn't be overwritten. 
Sylvain had the clever idea of adding listeners to the response 
environment, but I'm wondering if this wouldn't be too heavy since for 
every request a new set of listeners would have to be built.

Suggestions?

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com