:) 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] > >
