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]
