Personally, when I picked up Tapestry for development on a new project, the versioned assets (and the associated guarantee of "no stale assets"), was one of the reasons I found myself thinking that as much as I've banged my head against the wall on some no-so-trivial issues w/ Tapestry, it's worth working with a toolset that has thought through some of these pesky issues (e.g. compared to Grails where starting up was super easy; however, every time we re-deployed we had to tell customers to make sure they clear their cache and eventually roll out our own versioned assets solution).
If the framework goes the etags route, I really hope that it would be as foolproof as versioned assets. Cheers - Alex K On Mon, Jul 23, 2012 at 9:03 PM, Bob Harner <[email protected]> wrote: > I believe most Tapestry applications are deployed infrequently enough > that the current far-future-expires mechanism is the better approach, > at least as the default. I really love how lightweight (in terms of > number of requests) my Tapestry apps have been compared with other > frameworks I have used. > > On the other hand, if Tapestry could generate the asset version number > automatically (from an md5 checksum), that'd be even better, although > I'm sure I'm not seeing all of the implications of that. > > On Mon, Jul 23, 2012 at 8:19 PM, Howard Lewis Ship <[email protected]> > wrote: > > I've been doing some research on versioned URLs (the current standard > > for Tapestry) vs. ETags. > > > > The advantage of ETags is that we would no longer need to incorporate > > a version number into URLs, but could efficiently validate that the > > version of a file in the client browser's cache is up to date. The > > ETag could be just the md5 checksum of the contents of the server > > file; if the file contents have changed since the browser cached the > > content, then Tapestry sends the full content, including an updated > > ETag consisting of the MD5 checksum of the file contents. > > > > MD5 is fast and suitable for this purpose (but not for more demanding > > purposes, such as digital signatures). > > > > If the browser offers up the correct ETag then it has the right > > version and we respond with 304 (not modified). > > > > This is less efficient than our current approach; far-future expires > > header and a versioned url. With far-future/versioned the browser is > > informed that the file at that path will never change and can be > > cached aggressively, with no further requests to the server to see if > > there's been an update. > > > > With respect to yesterday's discussion of per-module version numbers: > > those would no longer be necessary with etags; the asset URL would be > > shorter, and would not incorporate any kind of version number. This > > would also make relative URLs (as sometimes used in CSS files) to be > > predictable. > > > > I think we're seeing a trade-off here: the versioned URL approach > > works well for infrequent, large-scale deployments. However, when one > > of those large-scale deployments occurs, then the cost is great: every > > connecting client will need to re-download every asset. > > > > With ETags; the cost of an incremental deployment is lower; most > > assets will not have changed; clients will requests the files, and be > > sent back a 304 if the file has not changed between deployments > > (regardless of whether the asset is part of the application, the > > Tapestry framework, or a third-party library). That means the server > > will receive more traffic, but will be sending inexpensive 304 > > responses much of the time. > > > > It is murky to me when the browser may decide to re-require an asset; > > this may take some experimentation. I'd hate to see applications where > > each page load is accompanied by a flurry of assets requests, all > > resulting in 304 responses. On the other hand, I'm also concerned > > about browsers running with mismatched assets, particularly, > > mismatched JavaScript libraries or modules. > > > > I suppose we could use the ETags approach, and use overrides of the > > the tapestry.asset-path-prefix symbol to change the asset URLs in a > > way that will force browsers to pull updates immediately. > > > > -- > > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
