With the ETag support in place, there's no longer any need for the module asset URLs to have a checksum or version number; they are no longer given a far-future expires header.
URLs (by default) look like "/modules/t5/core/dom.js" (where the module name is t5/core/dom). The application version number is no longer used in any URLs; it now exists just for documentation purposes (its written to the console at startup and in the exception report). This is good news, because you could screw yourself by deploying your application and NOT changing the version number (in 5.3.6). Very happy about this ... next up, thoughts on cometd/server-push support? On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <[email protected]>wrote: > > > On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <[email protected]>wrote: > >> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <[email protected] >> >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'll read this shortly. I've generally assumed that URLs with query > parameters are less likely to be cached in the browser, or served properly > by intermediate (reverse proxy) servers, but I haven't done the research. > > >> >> >> > 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 >> > > > > -- > 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 > -- 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
