Brian Warner wrote: > So the second idea is that, if your #hash=XYZ-validated jquery.js > library can be proven to be DeepFrozen (say, by passing it through the > Caja verifier with a flag that says "only accept DeepFrozen classes" or > something), then not only can you cache the javascript source code, but > you can also cache the parse tree, saving you the time and memory needed > to re-parse and evaluate the same source code on every single page load.
Actually you can cache the *parse tree* for a hash-validated library even without proving that the library is DeepFrozen. What you can't cache, just using hash validation, are any objects resulting from evaluating the library code. If you prove that the evaluation of such an object has no external side-effects and that it must be DeepFrozen, then you can cache that object as well. Your first idea to use hash validation to help with file caching seems more immediately practical. Incidentally, I obtained the XML source for the "Link Fingerprints" Internet Draft from Gervase Markham. I think we should reintroduce that draft -- perhaps with some minor technical changes such as a more compact encoding for the hash, rather than hexadecimal, and with some way to support both a fragment ID and a hash in the same URL. We could add the caching idea to the draft as additional rationale. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
