As discussed on a few threads and tracked in JIRA issue ( http://issues.apache.org/jira/browse/SHINDIG-579), we need to move rewriting logic out of AbstractHttpCache. Yet we should maintain rewritten content caching capability. The question is where to put it. I see two options, at a high level: 1. In code that calls ContentRewriterRegistry.rewrite(HttpResponse|Gadget). Eg. MakeRequestHandler, ProxyHandler, ViewContentFetcher, GadgetServer, and the near-future Renderer and Preloader. This allows finer-grained control over caching behavior in context, at the cost of distributing caching logic in various places. 2. In ContentRewriterRegistry.rewrite(HttpResponse|Gadget) itself, if so chosen. Caching logic can be consolidated in CachingContentRewriterRegistry, for instance (which will no longer subclass CachingWebRetrievalFactory), and be considered an optimization to rewriting.
I'm inclined to go #2. Rewriters themselves can be augmented with caching hints if necessary, and be assumed deterministic for a given cache key in the meantime. Consolidating rewriting logic makes it easier to share the cache itself. Still, I might be missing situations in which additional context inherent to the calling context is needed to make a caching decision. --John
