On Fri, Aug 29, 2008 at 1:43 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 27, 2008 at 5:47 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > You're 100% correct (on both the crack and the reasoning behind it). > Louis > > had some concern about the potential of two cache reads (not to mention > > maintaining two types of cache) as well as dealing with the rewriting in > > more than 1 place initially, but I think at this point it's safe to say > that > > the cure was worse than the disease and we should move this to a cleaner > > model. > > Ah, I love consensus! At the risk of breaking it, I'd like to suggest > that content rewriting should be implemented as a subclass of > ChainedContentFetcher. The chain would be: > > Caching -> Rewriting -> Authentication -> Network There are many things that need rewriting that don't involve an HTTP fetch (how would you model variable substitution or html wrapper appending in a rewriter that is operating on an HttpRequest?) Rewriting should be rewriting, HTTP fetching should be HTTP fetching, and caching should be caching. Trying to make everything look like HTTP requests has caused nothing but problems over the last few months, and we should not continue down that path. > > > The fetchers in the chain would collaborate to build up the cache key, > probably by exposing the makeCacheKey functions that are all private > at the moment. We'd still end up with a single cache read per > request. >
