On Tue, Sep 9, 2008 at 8:17 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > Excellent, agreed. CLs forthcoming.
Can you include the version numbers of the rewriters in the cache key? > > 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 >> > >> >
