To me, this discussion is on the wrong track: it's not ETag versus versioned urls but the kind of interfaces we should have to provide enough flexibility to support different mechanisms. Specifically, ETags is a client-side construct whereas versioned urls is a server side construct. With Etags, the browser will still be requesting the headers and the server has no control over it. These schemes are not necessarily contradictory and can be used together. One of the shining benefits of Tapestry 5 has always been the flexibility - if you don't like, override it. However, especially module specific versioning is quite impossible to achieve as the current services participating in asset url construction lose the context of where the asset came from.
With regards to module-specific versioning, I did some more investigation on it and I was quite surprised to find out how few libraries actually write their version to the manifest. Maven used to have this on by default but was switched off after the jar plugin version 2.1, which is quite a bummer. I blame Java specifications though, they could have have made it mandatory a long time ago. Anyway, perhaps Howard had been on this path already and discarded it for the above reasons. I still don't think we should or even could try to apply a single solution to address all the use cases. Dmitry Gusev had already solved this using asset urls with hashes, see http://dmitrygusev.blogspot.com/2012/03/serving-tapestry5-assets-as-static.html. That works well (and in most cases, better than a single application version embedded in all urls) for retrieving better assets. Most of my concerns would already be addressed if we offered this as a default or as an optional asset url scheme. Finally, I do agree with Alex about stale assets - when we were experimenting with different asset url schemes, we pretty quickly run into issues with stale resources in browser caches. Kalle On Mon, Jul 23, 2012 at 8:12 PM, Lenny Primak <[email protected]> wrote: > From reading Howard's post about the trade offs I see why far-future > expirations would be a better performing variant. I like bob's suggestion of > just using the md5 instead of a version number to keep track of assets. This > way thre is no version matching or hackers. > > > > On 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] >> > > --------------------------------------------------------------------- > 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]
