Re: Module-specific versioning of assets?

[Josh Canfield <jo...@gmail.com>]

:) 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 <hl...@gmail.com>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
> <ca...@axn-software.de> 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 <lp...@hope.nyc.ny.us>
> >> 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 <hl...@gmail.com>
> 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
> >>>> <th...@gmail.com> wrote:
> >>>>> Sounds good to me.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Jul 13, 2012, at 1:16 PM, Kalle Korhonen
> >>>>>> <ka...@gmail.com>
> >>>>>> 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: dev-unsubscribe@tapestry.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Thiago H. de Paula Figueiredo
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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: dev-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> 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: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

Re: Module-specific versioning of assets?

[Kalle Korhonen <ka...@gmail.com>]

The discussion was later broke into two thread when Howard posted
"Versioned URLs vs ETag" on July 23rd. In that thread I said:

On Mon, Jul 23, 2012 at 9:12 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> To me, this discussion is on the wrong track: it's not ETag versus
> versioned urls but the kind of interfaces we should have to provide
> enough flexibility to support different mechanisms. Specifically,
> ETags is a client-side construct whereas versioned urls is a server
> side construct. With Etags, the browser will still be requesting the
> headers and the server has no control over it. These schemes are not
> necessarily contradictory and can be used together. One of the shining
> benefits of Tapestry 5 has always been the flexibility - if you don't
> like, override it. However, especially module specific versioning is
> quite impossible to achieve as the current services participating in
> asset url construction lose the context of where the asset came from.
>
> With regards to module-specific versioning, I did some more
> investigation on it and I was quite surprised to find out how few
> libraries actually write their version to the manifest. Maven used to
> have this on by default but was switched off after the jar plugin
> version 2.1, which is quite a bummer. I blame Java specifications
> though, they could have have made it mandatory a long time ago.
> Anyway, perhaps Howard had been on this path already and discarded it
> for the above reasons.

I've been thinking about this more and I still agree with Josh that
module-specific versioning is still by far the easiest. Instead of
making it mandatory though, modules should just be able to opt-in. If
the module provides its own version as a contribution, we shouldn't be
applying any application-wide version to that path anymore. Wouldn't
that work well enough as a default strategy? Just to give an example a
a real word situation, we are deploying a new version once a week, and
5% (the highest) of the cumulative time since the last deployment is
spent on serving /assets/0.0.12/core/tree.css, which is a completely
unnecessary cost since we haven't updated the core version after
starting deployments.

Kalle


On Fri, Aug 24, 2012 at 2:36 PM, Josh Canfield <jo...@gmail.com> wrote:
> :) 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 <hl...@gmail.com>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
>> <ca...@axn-software.de> 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 <lp...@hope.nyc.ny.us>
>> >> 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 <hl...@gmail.com>
>> 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
>> >>>> <th...@gmail.com> wrote:
>> >>>>> Sounds good to me.
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Jul 13, 2012, at 1:16 PM, Kalle Korhonen
>> >>>>>> <ka...@gmail.com>
>> >>>>>> 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: dev-unsubscribe@tapestry.apache.org
>> >>>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Thiago H. de Paula Figueiredo
>> >>>>>
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> >>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> 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: dev-unsubscribe@tapestry.apache.org
>> >>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> 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: dev-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: dev-help@tapestry.apache.org
>> >
>>
>>
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org