Also moving the parts that relate to directly to the cache into the
cache would make more sense, eg from a 'cache' point of view, element
driven expiry in the cache should not need to know that its an http
element. Its relatively easy to implement below the cache abstraction
layer, if the interface to the cache has the concept of element
driven expiry.
Did the cache abstraction patches get applied (I cant remember
immediately, but will go and look).
Ian
On 11 Jul 2008, at 19:43, Kevin Brown wrote:
The whole http fetcher stack is a mess right now. Adding more
chaining isn't
going to help the situation.
Rewriting being done at the http fetcher level has also caused
several new
issues -- notably, rewriting gets done before message bundle
substitution,
which breaks a lot of things. Moving it out of the http stack
entirely seems
like it would be cleaner.
On Fri, Jul 11, 2008 at 11:31 AM, Brian Eaton <[EMAIL PROTECTED]>
wrote:
Hey -
I just discovered the content rewriting logic in AbstractHttpCache.
I'm not going to mess with it right now, but I wanted to test the
waters: how do people feel about making the content rewriting part of
the content fetching chain instead of burying it down in caching
logic?
I see that Kevin has considered moving this into gadget rendering:
https://issues.apache.org/jira/browse/SHINDIG-398.
Cheers,
Brian
