However, calculating those ETags is a bit tedious, especially when there is a lot of static resources.
My approach to this would be to have a background job that is started upon tapestry start up. It will precompute the etags for the various resources in the META-INF/assets directory, putting it into a file <resource-name>.etag. Upon (re)deploy of a given module or part of the application, the deployer will remove the existing etag files and the job would then recalculate the missing etags. As for getting the ETag for a given resource, a service would be used that will resolve the etag from the file, and if it is not there, it will create the etag file. This must be orchestrated with the background job, though, so that the two will not calculate the same Etag twice. And it must also be orchestrated across multiple requests to the same resource. The service could even use an LRUCache to cut down on file system access in order to speed things up. The deployer, however must be able to invalidate individual entries in the cache so that they get reloaded. Cheers -- Carsten > 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] > > -- Carsten Klein Mobil +491 577 666 256 5 [email protected] Alte Adresse gültig bis 2012-06-30: axn software UG (haftungsbeschränkt) Im TechnologiePark Bergisch Gladbach Friedrich-Ebert-Str. 51429 Bergisch Gladbach Neue Adresse gültig ab 2012-07-01: axn software UG (haftungsbeschränkt) Wipperfürther Str. 278 51515 Kürten Geschäftsführung Carsten Klein HRB 66732 Gerichtsstand Amtsgericht Köln Steuernummer 204/5710/1674 Umsatzsteuernr. DE 266 540 939 www.axn-software.de [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
