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]
