On Mon, Jul 14, 2008 at 10:08 AM, Louis Ryan <[EMAIL PROTECTED]> wrote:
> Brian
> This was actually how the original implementation worked and was later
> changed because we needed to ability to associate rewritten content with the
> cacheable version of the request and not the executed version of the
> request. See the OAuth and signing fetchers for examples of why this is
> important. Having the chained-fetchers do this just spreads the cache
> lookups throughout the code which isnt very DRY. A potential refactoring
> would be to allow for injecting cache entry pre/post processors into the
> cache.
The way I'd like to do this would work as follows:
- any content fetcher that needs special handling of cached content
(which is pretty much all of them) exposes an interface to generate an
appropriate cache key
- we thwack a CacheContentFetcher on the front of the fetching chain
that knows what do with cache keys.
So the CacheContentFetcher looks something like this:
key = nextFetcher.getCacheKey(request)
if (key in cache) {
return cached content
}
content = nextFetcher.fetch(request)
cache.put(key, content)
The rewriting content fetcher would sit between the cached content
fetcher and the other fetchers in the chain (e.g signing, oauth, or
anything else). It's getCacheKey method would look something like
this:
key = nextFetcher.getCacheKey(request)
if (shouldRewrite(request)) {
key.addParameter("rewritten", "true")
}
return key;
So the fetching chain would look like this:
caching -> rewriting -> [authentication] -> remote content fetcher
This would be pleasant because then we wouldn't need to sprinkle cache
lookups throughout all of the fetchers. Each fetcher would need to
know how to generate an appropriate cache key, but wouldn't need a
handle to the actual cache and wouldn't need to worry about how to do
lookups.
Cheers,
Brian
