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
