Ooo. I like this idea! It simplifies things
On Jul 23, 2012, at 3:49 PM, "Carsten Klein" <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
