I agree with that. Makes it very, very fast On Mar 12, 2013, at 6:31 AM, Bob Harner wrote:
> As a Tapestry user, I agree with your preference to prevent asset > requests entirely rather than go the chattier ETag route. I would > rather give up on the checksums-in-URLs idea (at least for modules) > than have any significant increase in the number of requests to the > server. > > I think Tapestry's far-future expires headers is one of its best features. > > On Mon, Mar 11, 2013 at 4:35 PM, 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. >> >> 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
