In general, it _can_ be based on any metadata in the Gadget or HttpResponse and HttpRequest objects. Since ultimately rewriting is just running a succession of ContentRewriters over some object(s), with String input and String output, at present I'm thinking the key is: <list-of-contributing-rewriters-with-version-numbers>+<input-string-hashcode>
The cache itself is String -> String. The main limitation with this is that it assumes that rewriting only occurs on "payload" content that can be expressed in String form. If other modifications to Gadget or HttpResponse are required (ie. to HttpResponse headers) in the future, those will need to participate in the key. --John On Tue, Sep 9, 2008 at 3:58 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > 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>? > > Hmm. Maybe it isn't necessary. Can you explain the caching algorithm > for the rewriters? I thought it must be based on URL, but if it > isn't, maybe there's no problem. >
