The discussion was later broke into two thread when Howard posted "Versioned URLs vs ETag" on July 23rd. In that thread I said:
On Mon, Jul 23, 2012 at 9:12 PM, Kalle Korhonen <[email protected]> wrote: > 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've been thinking about this more and I still agree with Josh that module-specific versioning is still by far the easiest. Instead of making it mandatory though, modules should just be able to opt-in. If the module provides its own version as a contribution, we shouldn't be applying any application-wide version to that path anymore. Wouldn't that work well enough as a default strategy? Just to give an example a a real word situation, we are deploying a new version once a week, and 5% (the highest) of the cumulative time since the last deployment is spent on serving /assets/0.0.12/core/tree.css, which is a completely unnecessary cost since we haven't updated the core version after starting deployments. Kalle On Fri, Aug 24, 2012 at 2:36 PM, Josh Canfield <[email protected]> wrote: > :) catching up on old threads. > >> I for my part also think that with HTTP's Cache-Control, ETag and Expires >> headers there is actually no need for reinvoking late 80s/90s URL >> scrambling by adding random identifiers to the URL. > > Ah, the good old days of 80's web programming... ;) > > Seriously though, using HTTP Cache-Control is great for resources that are > changing during the life of a deployment. But I think it's inappropriate > for assets that are deployed as part of the application. I don't want to > see all those 304s. It's better that the client holds the asset for as long > as it will so that it doesn't have to slow down to make the request and the > server doesn't have to spend any cycles on them. > > Versioned paths FTW! > > Josh > > On Mon, Jul 23, 2012 at 12:34 PM, Howard Lewis Ship <[email protected]>wrote: > >> That's a good point; maybe we need to switch from far-future expires >> header and versioned URL to proper use of E-Tags; but we still have to >> provide correct E-Tag information on a asset by asset basis. The >> date-time-modified is usually innaccurate or unhelpful, once packaged >> inside a JAR. >> >> On Mon, Jul 23, 2012 at 12:09 PM, Carsten Klein >> <[email protected]> wrote: >> > >> > I for my part also think that with HTTP's Cache-Control, ETag and Expires >> > headers there is actually no need for reinvoking late 80s/90s URL >> > scrambling by adding random identifiers to the URL. >> > >> > Modern user agents will use the ETag and thus enforce reloading of a >> > resource currently in cache, in case that the ETags do not match. >> > >> > -1 for randomizing/versioning assets. >> > >> > >> > Cheers >> > -- Carsten >> > >> > >> >> One of the advantages of the single version number as implemented in >> >> 5.3, is that (from the client's point of view) the hierachy of assets >> >> is simple and predictable. >> >> >> >> I've leveraged this in the past to have a CSS in a library use a >> >> ../core relative URL to access an asset packaged with the core >> >> framework. >> >> >> >> If every module has its own version number, that kind of relative url >> >> (rare but useful) would no longer be possible, since it would have to >> >> be ../../123abc/core (where "123abc" is the core version number, and >> >> not statically predictable). >> >> >> >> This may not be a big issue however; I've been thinking about how to >> >> aggregate CSS as we do JS; the first step there is to expand all url() >> >> references to absolute paths anyway. >> >> >> >> On Fri, Jul 13, 2012 at 4:39 PM, Lenny Primak <[email protected]> >> >> wrote: >> >>> I like the optional version number idea. I don't think it's impossible >> >>> to track asset versions by module. >> >>> You could make it a dual alias, I.e. both referenceable by the >> >>> application version and by module version. It can be a bit more >> flexible >> >>> without any sacrifices. >> >>> >> >>> >> >>> >> >>> On Jul 13, 2012, at 2:36 PM, Howard Lewis Ship <[email protected]> >> wrote: >> >>> >> >>>> Earlier versions of Tapestry tried to track versions of each library >> >>>> separately; you had to contribute a LibraryMapping to >> >>>> ComponentClassResourceResolver, and contribute a seperate value to >> >>>> ClasspathAssetAliasManager that included your version number. That >> >>>> was a lot of work and was error prone, which is why 5.2 switched to >> >>>> the one-version-number-to-rule-them-all. >> >>>> >> >>>> The upcoming module stuff will make version numbers even more >> >>>> important. I don't see a viable middle ground currently, though >> >>>> that's short of saying it is impossible. Perhaps there's a way that we >> >>>> could define an optional library version number, that would default to >> >>>> the application version number. >> >>>> >> >>>> On the other hand, I expect that 5.4 will be much "lighter" in its use >> >>>> of JavaScript as the use of stand-alone libraries & stacks will start >> >>>> to switch over to modules, which are loaded in parallel and as needed. >> >>>> By 5.5, stacks and libraries should be the rare exception, and >> >>>> modules the main approach. >> >>>> >> >>>> I'm still working on many of the details, including whether and how to >> >>>> aggregate modules into stacks for efficient preloading. >> >>>> >> >>>> As a side note, I expect that by 5.5 we'll require that all classpath >> >>>> assets made visible to the user be moved from the main class path to >> >>>> folders under META-INF/assets. I.e., >> >>>> "com/example/foolib/components/MyLib.js". I'm not quite sure what the >> >>>> folder structure will be; possibly just parallel packages, just rooted >> >>>> under META-INF/assets/ instead of /. >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Jul 13, 2012 at 11:17 AM, Thiago H de Paula Figueiredo >> >>>> <[email protected]> wrote: >> >>>>> Sounds good to me. >> >>>>> >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Jul 13, 2012, at 1:16 PM, Kalle Korhonen >> >>>>>> <[email protected]> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> We are deploying our app to production once a week and I find it >> >>>>>>> quite >> >>>>>>> annoying that every time we basically force our users to >> re-download >> >>>>>>> all of the application resources even though only a small subset of >> >>>>>>> them changed, causing wasted bandwidth and perceived performance >> >>>>>>> issues. At the same time, we cannot afford users to have stale >> >>>>>>> resources in their caches. All of the Tynamo.org modules add their >> >>>>>>> own >> >>>>>>> version to asset paths so adding the application version is >> >>>>>>> completely >> >>>>>>> redundant, for example: >> >>>>>>> >> >>>>>>> >> http://localhost:8080/assets/0.0.1-SNAPSHOT-1341940822046/facebook-0.1.0/components/fb-button.css >> >>>>>>> >> >>>>>>> We briefly looked into generically changing how asset paths are >> >>>>>>> constructed to include module's own version but it's difficult to >> >>>>>>> achieve because the context (from which module the asset came) is >> >>>>>>> lost. >> >>>>>>> >> >>>>>>> Tynamo modules contribute something like: >> >>>>>>> public static void >> >>>>>>> contributeClasspathAssetAliasManager(MappedConfiguration<String, >> >>>>>>> String> configuration) >> >>>>>>> { >> >>>>>>> configuration.add(PATH_PREFIX + "-" + version, >> >>>>>>> "org/tynamo/security"); >> >>>>>>> } >> >>>>>>> >> >>>>>>> What if we implemented a ClassPathAssetAliasManager2 that would >> take >> >>>>>>> a >> >>>>>>> MappedConfiguration<String, Package> so we could automatically do >> >>>>>>> the >> >>>>>>> same as above for add-on modules, using >> >>>>>>> Package.getImplementationVersion()? >> >>>>>>> >> >>>>>>> It would encourage the (best) practice of placing the main module >> >>>>>>> class to the intended root package of a module, and it'd be very >> >>>>>>> simple to contribute in the module like so: >> >>>>>>> public static void >> >>>>>>> contributeClasspathAssetAliasManager2(MappedConfiguration<String, >> >>>>>>> Package> configuration) >> >>>>>>> { >> >>>>>>> configuration.add(PATH_PREFIX, getClass().getPackage() ); >> >>>>>>> } >> >>>>>>> >> >>>>>>> Similarly, LibraryMapping (a contribution to >> ComponentClassResolver) >> >>>>>>> could also accept a Package, rather than just a string. >> >>>>>>> >> >>>>>>> What do you think? >> >>>>>>> >> >>>>>>> Kalle >> >>>>>>> >> >>>>>>> >> --------------------------------------------------------------------- >> >>>>>>> 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] >> >>>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Thiago H. de Paula Figueiredo >> >>>>> >> >>>>> >> >>>>> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: [email protected] >> >>>>> For additional commands, e-mail: [email protected] >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> 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] >> >>> >> >> >> >> >> >> >> >> -- >> >> 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] >> > >> >> >> >> -- >> 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]
