Excellent, agreed. CLs forthcoming. On Tue, Sep 9, 2008 at 12:14 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> #2 is the only really viable option. If we have to put caching logic in 10 > different places we'll screw it up 9 different times :). > > On Tue, Sep 9, 2008 at 12:11 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > > > 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 > > >
