On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hls...@gmail.com>wrote:
> 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. > > It depends on where you put the checksum. If you put it as a GET parameter - then no relative URLs will be broken. Have you read my blog post about Tapestry5 checksums in assets? http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html > 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 > -- Dmitry Gusev AnjLab Team http://anjlab.com
