The versioning should be more explicit than that I think. Maybe add a getVersion function to the rewriter interface so they can manage their own changes
On Tue, Sep 9, 2008 at 12:39 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > Interesting suggestion. I can include the rewriter class names and their > class hash codes or some other such versioning construct. > > On Tue, Sep 9, 2008 at 12:32 PM, Ben Laurie <[EMAIL PROTECTED]> wrote: > > > 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 > > >> > > > >> > > > > > >
