On Tue, Sep 9, 2008 at 4:07 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote:
> 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. Is that input stream hashcode or a string fingerprint? String.hashCode is only 32 bits long, which would make for many collisions. An md5 of the body contents will avoid most of that. > > > --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. > > >
