I've been working, a few hours a week, on getting per-asset checksums into URLs.
Some parts of this have been a challenge to accomplish without completely breaking the Asset interface and a bunch of public services. For ordinary assets, it's pretty easy ... but for aggregated JavaScript libraries its been a pain that's affected a bunch of stuff. CSS files are now rewritten, since relative URLs will be broken by the addition of the checksum. I have a first (but not final) pass at this, where url() patterns in the CSS are converted into complete paths. This also opens the door to CSS aggregation as well as JavaScript aggregation. I still don't have a great solution for JavaScript modules; RequireJS/AMD expect that there's a common root folder name (such as "/assets/modules/"), and module "a/b" is simply "*root*/a/b.js". For individual modules, you can write your own overrides. In fact, Tapestry has to strip off the ".js' part (which is hard-wired by RequireJS) because the actual server-side resource could be CoffeeScript or some other language that compiles to JavaScript. Short of iterating all server-side module files and writing a RequireJS config for each one (mapping each name to a URL with an embedded checksum), there isn't a great solution. Alternately, something could iterate all the server-side modules and built a composite checksum, but there are at least a couple of virtual modules generated at runtime (and locale specific for extra kicks). Modules may have to stay on the 5.3 approach: using the application version number for everything. Finding the sweet spot where assets of all kinds (CSS, JavaScript libraries, JavaScript modules, etc.) can be changed freely and the URLs automatically reflect the actual content (that is, include a checksum of that content) for ideal client-side caching ... may simply be out of reach. Perhaps for modules we should use an alternate approach based on ETags ( http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would not need to be any version number of checksum in a module URL, but clients would request the module content more often (and based on ETag, would often get a 304 Not Modified). I would prefer to see a URL that changes when the content changes (which prevents the request entirely). -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
