cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: CachingProcessingPipeline: new Expires code
Date Tue, 25 Feb 2003 12:39:05 GMT

Gianugo Rabellino wrote:
> > Ah ok, does this mean that if an expires date is set, you want to
> > cache the pipeline, regardless if all components in this 
> pipeline support
> > the Cacheable... interface?
> 
> Exactly. Meaning that the "expires" setting is a way to tell the 
> pipeline engine that you know better if and how long a resource is valid.
> 
> > I think, it is much better to completly remove this expires handling
> > from the current caching implementation and great an own 
> expires pipeline
> > implementation, that simply checks for the expire parameter and don't
> > care about the key/validity handling. This is why we now have 
> the pipelines
> > as own components, so we can make different implementations and don't
> > need to put everything into one implementation.
> 
> I've been thinking about it, and indeed it might make sense. My point, 
> however, is that there are two sides to consider:
> 
> 1. this ExpiresEnabledCachingProcessingPipeline would rely *a lot* on 
> the CachingProcessingPipeline, meaning that it would just be an 
> extension built on top of it and "falling back" to the default 
> implementation if an expires is not (anymore?) provided, so I'm not dead 
> sure that having a separate implementation is the best way to go, also 
> because of usability concerns;
> 
I see your point, but I'm not quiet sure if this is the way it should be.
If an expires date is set, the complete response is cached for this
duration - this is a simple 5 line implementation ( :) just kidding) where
you don't need much of the current caching implementation.
If no expires is set, well...then don't cache, perhaps.

> 2. HTTP expires: it should be in theory possible to set them from any 
> pipeline (and definitely this is what happens, since the code is in 
> AbstractProcessingPipeline), but I'm afraid it would be somehow 
> misleading to have a different behaviour (no internal use) depending on 
> the actual caching pipeline implementation.
Yes, I think it was me who put it into the AbstractProcessingPipeline, but
perhaps it's not correct at that place.

> 
> Agreed, anyhow: it would be cleaner, and I'll think about it. It would 
> also be the case to understand if and how this code might be integrated 
> in the CachingPointProcessingPipeline. Suggestions?
> 
No, hmm...really complicated...to be honest, I have currently no clue.

Carsten

Mime
View raw message