I briefly considered String hashCode, but quickly recognized that was a bad idea. MD5 of contents sounds reasonable. Brian, thoughts?
On Tue, Sep 9, 2008 at 4:23 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > 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. > > > > > >
