tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lenny Primak <lpri...@hope.nyc.ny.us>
Subject Re: Coming soon: per-Asset checkums in URLs
Date Tue, 12 Mar 2013 15:46:41 GMT
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 <hlship@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message