This isn't a problem if we incorporate Brian's signing fetch patch and make it so that the HttpCacheKey can generate the key without any other objects.
On Tue, Sep 9, 2008 at 3:18 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > This might be a problem -- the rewriter registry has no knowledge of its > calling context, and I'm loath to add specific caching APIs/parameters to > its methods unless absolutely necessary. Can you say more about why this is > required? In what way can't the rewriting behavior in this case key on > <rewriters>+<input string hash>? > John > > On Tue, Sep 9, 2008 at 3:10 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > On Tue, Sep 9, 2008 at 12:11 PM, John Hjelmstad <[EMAIL PROTECTED]> > wrote: > > > Still, I might be missing situations in which additional context > inherent > > to > > > the calling context is needed to make a caching decision. > > > > OAuthFetcher needs to have input in to the generation of the cache key > > for any authenticated requests. There is a function getCacheKey in > > OAuthFetcher that is currently private, I think you'll want to make it > > public. > > >
