You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2013/03/11 21:35:11 UTC
Coming soon: per-Asset checkums in URLs
I've been working, a few hours a week, on getting per-asset checksums into
URLs.
Some parts of this have been a challenge to accomplish without completely
breaking the Asset interface and a bunch of public services.
For ordinary assets, it's pretty easy ... but for aggregated JavaScript
libraries its been a pain that's affected a bunch of stuff.
CSS files are now rewritten, since relative URLs will be broken by the
addition of the checksum. I have a first (but not final) pass at this,
where url() patterns in the CSS are converted into complete paths. This
also opens the door to CSS aggregation as well as JavaScript aggregation.
I still don't have a great solution for JavaScript modules; RequireJS/AMD
expect that there's a common root folder name (such as "/assets/modules/"),
and module "a/b" is simply "*root*/a/b.js". For individual modules, you can
write your own overrides. In fact, Tapestry has to strip off the ".js'
part (which is hard-wired by RequireJS) because the actual server-side
resource could be CoffeeScript or some other language that compiles to
JavaScript.
Short of iterating all server-side module files and writing a RequireJS
config for each one (mapping each name to a URL with an embedded checksum),
there isn't a great solution. Alternately, something could iterate all the
server-side modules and built a composite checksum, but there are at least
a couple of virtual modules generated at runtime (and locale specific for
extra kicks).
Modules may have to stay on the 5.3 approach: using the application version
number for everything.
Finding the sweet spot where assets of all kinds (CSS, JavaScript
libraries, JavaScript modules, etc.) can be changed freely and the URLs
automatically reflect the actual content (that is, include a checksum of
that content) for ideal client-side caching ... may simply be out of reach.
Perhaps for modules we should use an alternate approach based on ETags (
http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would not
need to be any version number of checksum in a module URL, but clients
would request the module content more often (and based on ETag, would often
get a 304 Not Modified). I would prefer to see a URL that changes when the
content changes (which prevents the request entirely).
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
I haven't looked at tapestry-cometd as I want to come up with a fresh,
unhindered approach. Or perhaps we should just look to adopt the code into
tapestry-core?
On Mon, Apr 8, 2013 at 8:23 PM, Taha Hafeez Siddiqi <
tawus.tapestry@gmail.com> wrote:
> Agree with Bob as far as chat applications are concerned.
>
> I recently worked on a cometd-tapestry chat application and I was doing a
> lot more in javascript than in tapestry although I did integrate
> tapestry-security and tapestry-ioc which made the job a lot easier.
>
> BTW, there is already a tapestry-cometd module by Lance.
>
> regards
> Taha
>
> On 09-Apr-2013, at 7:13 AM, Bob Harner <bo...@gmail.com> wrote:
>
> > Doesn't the switch to ETags for modules make for much chattier web apps,
> > with lots more "conditional GET" requests for JS modules coming in after
> > every page request?
> >
> > In any case, good riddance to the application version numbers.
> >
> > On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
> >
> >> With the ETag support in place, there's no longer any need for the
> module
> >> asset URLs to have a checksum or version number; they are no longer
> given a
> >> far-future expires header.
> >>
> >> URLs (by default) look like "/modules/t5/core/dom.js" (where the module
> >> name is t5/core/dom).
> >>
> >> The application version number is no longer used in any URLs; it now
> exists
> >> just for documentation purposes (its written to the console at startup
> and
> >> in the exception report). This is good news, because you could screw
> >> yourself by deploying your application and NOT changing the version
> number
> >> (in 5.3.6).
> >>
> >> Very happy about this ... next up, thoughts on cometd/server-push
> support?
> >>
> >>
> >>
> >> On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hlship@gmail.com
> >>> wrote:
> >>
> >>>
> >>>
> >>> On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >>> wrote:
> >>>
> >>>> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hlship@gmail.com
> >>>>> wrote:
> >>>>
> >>>>> I've been working, a few hours a week, on getting per-asset checksums
> >>>> into
> >>>>> URLs.
> >>>>>
> >>>>> Some parts of this have been a challenge to accomplish without
> >>>> completely
> >>>>> breaking the Asset interface and a bunch of public services.
> >>>>>
> >>>>> For ordinary assets, it's pretty easy ... but for aggregated
> >> JavaScript
> >>>>> libraries its been a pain that's affected a bunch of stuff.
> >>>>>
> >>>>> CSS files are now rewritten, since relative URLs will be broken by
> the
> >>>>> addition of the checksum. I have a first (but not final) pass at
> this,
> >>>>
> >>>> where url() patterns in the CSS are converted into complete paths.
> This
> >>>>> also opens the door to CSS aggregation as well as JavaScript
> >>>> aggregation.
> >>>>>
> >>>>>
> >>>> It depends on where you put the checksum.
> >>>> If you put it as a GET parameter - then no relative URLs will be
> broken.
> >>>>
> >>>> Have you read my blog post about Tapestry5 checksums in assets?
> >>>>
> >>>>
> >>
> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
> >>>
> >>>
> >>> I'll read this shortly. I've generally assumed that URLs with query
> >>> parameters are less likely to be cached in the browser, or served
> >> properly
> >>> by intermediate (reverse proxy) servers, but I haven't done the
> research.
> >>>
> >>>
> >>>>
> >>>>
> >>>>> I still don't have a great solution for JavaScript modules;
> >>>> RequireJS/AMD
> >>>>> expect that there's a common root folder name (such as
> >>>> "/assets/modules/"),
> >>>>> and module "a/b" is simply "*root*/a/b.js". For individual modules,
> >> you
> >>>> can
> >>>>> write your own overrides. In fact, Tapestry has to strip off the
> >> ".js'
> >>>>> part (which is hard-wired by RequireJS) because the actual
> server-side
> >>>>> resource could be CoffeeScript or some other language that compiles
> to
> >>>>> JavaScript.
> >>>>>
> >>>>> Short of iterating all server-side module files and writing a
> >> RequireJS
> >>>>> config for each one (mapping each name to a URL with an embedded
> >>>> checksum),
> >>>>> there isn't a great solution. Alternately, something could iterate
> >> all
> >>>> the
> >>>>> server-side modules and built a composite checksum, but there are at
> >>>> least
> >>>>> a couple of virtual modules generated at runtime (and locale specific
> >>>> for
> >>>>> extra kicks).
> >>>>>
> >>>>> Modules may have to stay on the 5.3 approach: using the application
> >>>> version
> >>>>> number for everything.
> >>>>>
> >>>>> Finding the sweet spot where assets of all kinds (CSS, JavaScript
> >>>>> libraries, JavaScript modules, etc.) can be changed freely and the
> >> URLs
> >>>>> automatically reflect the actual content (that is, include a checksum
> >> of
> >>>>> that content) for ideal client-side caching ... may simply be out of
> >>>> reach.
> >>>>>
> >>>>> Perhaps for modules we should use an alternate approach based on
> >> ETags (
> >>>>> http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there
> >> would
> >>>>> not
> >>>>> need to be any version number of checksum in a module URL, but
> clients
> >>>>> would request the module content more often (and based on ETag, would
> >>>> often
> >>>>> get a 304 Not Modified). I would prefer to see a URL that changes
> >> when
> >>>> the
> >>>>> content changes (which prevents the request entirely).
> >>>>>
> >>>>> --
> >>>>> 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
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Dmitry Gusev
> >>>>
> >>>> AnjLab Team
> >>>> http://anjlab.com
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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
> >>>
> >>
> >>
> >>
> >> --
> >> 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
>
>
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Taha Hafeez Siddiqi <ta...@gmail.com>.
Agree with Bob as far as chat applications are concerned.
I recently worked on a cometd-tapestry chat application and I was doing a lot more in javascript than in tapestry although I did integrate tapestry-security and tapestry-ioc which made the job a lot easier.
BTW, there is already a tapestry-cometd module by Lance.
regards
Taha
On 09-Apr-2013, at 7:13 AM, Bob Harner <bo...@gmail.com> wrote:
> Doesn't the switch to ETags for modules make for much chattier web apps,
> with lots more "conditional GET" requests for JS modules coming in after
> every page request?
>
> In any case, good riddance to the application version numbers.
>
> On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> With the ETag support in place, there's no longer any need for the module
>> asset URLs to have a checksum or version number; they are no longer given a
>> far-future expires header.
>>
>> URLs (by default) look like "/modules/t5/core/dom.js" (where the module
>> name is t5/core/dom).
>>
>> The application version number is no longer used in any URLs; it now exists
>> just for documentation purposes (its written to the console at startup and
>> in the exception report). This is good news, because you could screw
>> yourself by deploying your application and NOT changing the version number
>> (in 5.3.6).
>>
>> Very happy about this ... next up, thoughts on cometd/server-push support?
>>
>>
>>
>> On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hlship@gmail.com
>>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dmitry.gusev@gmail.com
>>> wrote:
>>>
>>>> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hlship@gmail.com
>>>>> wrote:
>>>>
>>>>> I've been working, a few hours a week, on getting per-asset checksums
>>>> into
>>>>> URLs.
>>>>>
>>>>> Some parts of this have been a challenge to accomplish without
>>>> completely
>>>>> breaking the Asset interface and a bunch of public services.
>>>>>
>>>>> For ordinary assets, it's pretty easy ... but for aggregated
>> JavaScript
>>>>> libraries its been a pain that's affected a bunch of stuff.
>>>>>
>>>>> CSS files are now rewritten, since relative URLs will be broken by the
>>>>> addition of the checksum. I have a first (but not final) pass at this,
>>>>
>>>> where url() patterns in the CSS are converted into complete paths. This
>>>>> also opens the door to CSS aggregation as well as JavaScript
>>>> aggregation.
>>>>>
>>>>>
>>>> It depends on where you put the checksum.
>>>> If you put it as a GET parameter - then no relative URLs will be broken.
>>>>
>>>> Have you read my blog post about Tapestry5 checksums in assets?
>>>>
>>>>
>> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
>>>
>>>
>>> I'll read this shortly. I've generally assumed that URLs with query
>>> parameters are less likely to be cached in the browser, or served
>> properly
>>> by intermediate (reverse proxy) servers, but I haven't done the research.
>>>
>>>
>>>>
>>>>
>>>>> I still don't have a great solution for JavaScript modules;
>>>> RequireJS/AMD
>>>>> expect that there's a common root folder name (such as
>>>> "/assets/modules/"),
>>>>> and module "a/b" is simply "*root*/a/b.js". For individual modules,
>> you
>>>> can
>>>>> write your own overrides. In fact, Tapestry has to strip off the
>> ".js'
>>>>> part (which is hard-wired by RequireJS) because the actual server-side
>>>>> resource could be CoffeeScript or some other language that compiles to
>>>>> JavaScript.
>>>>>
>>>>> Short of iterating all server-side module files and writing a
>> RequireJS
>>>>> config for each one (mapping each name to a URL with an embedded
>>>> checksum),
>>>>> there isn't a great solution. Alternately, something could iterate
>> all
>>>> the
>>>>> server-side modules and built a composite checksum, but there are at
>>>> least
>>>>> a couple of virtual modules generated at runtime (and locale specific
>>>> for
>>>>> extra kicks).
>>>>>
>>>>> Modules may have to stay on the 5.3 approach: using the application
>>>> version
>>>>> number for everything.
>>>>>
>>>>> Finding the sweet spot where assets of all kinds (CSS, JavaScript
>>>>> libraries, JavaScript modules, etc.) can be changed freely and the
>> URLs
>>>>> automatically reflect the actual content (that is, include a checksum
>> of
>>>>> that content) for ideal client-side caching ... may simply be out of
>>>> reach.
>>>>>
>>>>> Perhaps for modules we should use an alternate approach based on
>> ETags (
>>>>> http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there
>> would
>>>>> not
>>>>> need to be any version number of checksum in a module URL, but clients
>>>>> would request the module content more often (and based on ETag, would
>>>> often
>>>>> get a 304 Not Modified). I would prefer to see a URL that changes
>> when
>>>> the
>>>>> content changes (which prevents the request entirely).
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Dmitry Gusev
>>>>
>>>> AnjLab Team
>>>> http://anjlab.com
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> 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: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'm not sure that the browsers will cache resources with parameters
as aggressively as those with just path. I could be wrong.
To me, putting the checksum into the URL as a parameter is something of a
hack that's done because there isn't the same infrastructure that Tapestry
has for building and dispatching the URLs.
The theory of the ETags is that another server, such as the firewall proxy,
could cache the files at that layer, and prevent the request from moving
inwards to the servlet container at all.
If we incorporate the checksum into the module URL (even as a GET
parameter), it will require Tapestry to locate every possible module
(including "virtual" modules that are generated at runtime) and write a
large block of JSON mapping each module to its corresponding URL. That's
just how AMD operates.
On Tue, Apr 9, 2013 at 12:21 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> I agree with Bob, isn't the whole idea of asset checksums and far-future
> expire
> headers was to reduce number of HTTP requests?
>
> Whats the advantage of ETags then?
> I bet the majority of assets for which HTTP 304 Not Modified would
> be returned would weight pretty much the same (in bytes) as returned 304
> response.
>
> I'd normally use Etag when I had to implement some transactional state in
> some REST conversation.
>
> Keep in mind that, for instance, on AppEngine (or name any other cloud
> provider) such request could cost much
> more that just returning 304 -- AppEngine could start a new instance of
> application to serve this request.
> So I think for assets the main goal is reducing number of requests, but not
> optimizing the payload.
>
>
> Btw,
>
> > I've generally assumed that URLs with query
> > parameters are less likely to be cached in the browser, or served
> properly
> > by intermediate (reverse proxy) servers, but I haven't done the research.
>
> I noticed you've integrated checksums into the path of URL, not as GET
> parameters...
>
> Do you have any reason for this? Done any research?
> Because I'm seeing this pattern with GET parameters
> is widely abopted on the web and it works good.
>
>
> On Tue, Apr 9, 2013 at 5:43 AM, Bob Harner <bo...@gmail.com> wrote:
>
> > Doesn't the switch to ETags for modules make for much chattier web apps,
> > with lots more "conditional GET" requests for JS modules coming in after
> > every page request?
> >
> > In any case, good riddance to the application version numbers.
> >
> > On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hl...@gmail.com>
> > wrote:
> >
> > > With the ETag support in place, there's no longer any need for the
> module
> > > asset URLs to have a checksum or version number; they are no longer
> > given a
> > > far-future expires header.
> > >
> > > URLs (by default) look like "/modules/t5/core/dom.js" (where the module
> > > name is t5/core/dom).
> > >
> > > The application version number is no longer used in any URLs; it now
> > exists
> > > just for documentation purposes (its written to the console at startup
> > and
> > > in the exception report). This is good news, because you could screw
> > > yourself by deploying your application and NOT changing the version
> > number
> > > (in 5.3.6).
> > >
> > > Very happy about this ... next up, thoughts on cometd/server-push
> > support?
> > >
> > >
> > >
> > > On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hlship@gmail.com
> > > >wrote:
> > >
> > > >
> > > >
> > > > On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <
> dmitry.gusev@gmail.com
> > > >wrote:
> > > >
> > > >> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <
> hlship@gmail.com
> > > >> >wrote:
> > > >>
> > > >> > I've been working, a few hours a week, on getting per-asset
> > checksums
> > > >> into
> > > >> > URLs.
> > > >> >
> > > >> > Some parts of this have been a challenge to accomplish without
> > > >> completely
> > > >> > breaking the Asset interface and a bunch of public services.
> > > >> >
> > > >> > For ordinary assets, it's pretty easy ... but for aggregated
> > > JavaScript
> > > >> > libraries its been a pain that's affected a bunch of stuff.
> > > >> >
> > > >> > CSS files are now rewritten, since relative URLs will be broken by
> > the
> > > >> > addition of the checksum. I have a first (but not final) pass at
> > this,
> > > >>
> > > >> where url() patterns in the CSS are converted into complete paths.
> > This
> > > >> > also opens the door to CSS aggregation as well as JavaScript
> > > >> aggregation.
> > > >> >
> > > >> >
> > > >> It depends on where you put the checksum.
> > > >> If you put it as a GET parameter - then no relative URLs will be
> > broken.
> > > >>
> > > >> Have you read my blog post about Tapestry5 checksums in assets?
> > > >>
> > > >>
> > >
> >
> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
> > > >
> > > >
> > > > I'll read this shortly. I've generally assumed that URLs with query
> > > > parameters are less likely to be cached in the browser, or served
> > > properly
> > > > by intermediate (reverse proxy) servers, but I haven't done the
> > research.
> > > >
> > > >
> > > >>
> > > >>
> > > >> > I still don't have a great solution for JavaScript modules;
> > > >> RequireJS/AMD
> > > >> > expect that there's a common root folder name (such as
> > > >> "/assets/modules/"),
> > > >> > and module "a/b" is simply "*root*/a/b.js". For individual
> modules,
> > > you
> > > >> can
> > > >> > write your own overrides. In fact, Tapestry has to strip off the
> > > ".js'
> > > >> > part (which is hard-wired by RequireJS) because the actual
> > server-side
> > > >> > resource could be CoffeeScript or some other language that
> compiles
> > to
> > > >> > JavaScript.
> > > >> >
> > > >> > Short of iterating all server-side module files and writing a
> > > RequireJS
> > > >> > config for each one (mapping each name to a URL with an embedded
> > > >> checksum),
> > > >> > there isn't a great solution. Alternately, something could
> iterate
> > > all
> > > >> the
> > > >> > server-side modules and built a composite checksum, but there are
> at
> > > >> least
> > > >> > a couple of virtual modules generated at runtime (and locale
> > specific
> > > >> for
> > > >> > extra kicks).
> > > >> >
> > > >> > Modules may have to stay on the 5.3 approach: using the
> application
> > > >> version
> > > >> > number for everything.
> > > >> >
> > > >> > Finding the sweet spot where assets of all kinds (CSS, JavaScript
> > > >> > libraries, JavaScript modules, etc.) can be changed freely and the
> > > URLs
> > > >> > automatically reflect the actual content (that is, include a
> > checksum
> > > of
> > > >> > that content) for ideal client-side caching ... may simply be out
> of
> > > >> reach.
> > > >> >
> > > >> > Perhaps for modules we should use an alternate approach based on
> > > ETags (
> > > >> > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there
> > > would
> > > >> > not
> > > >> > need to be any version number of checksum in a module URL, but
> > clients
> > > >> > would request the module content more often (and based on ETag,
> > would
> > > >> often
> > > >> > get a 304 Not Modified). I would prefer to see a URL that changes
> > > when
> > > >> the
> > > >> > content changes (which prevents the request entirely).
> > > >> >
> > > >> > --
> > > >> > 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
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Dmitry Gusev
> > > >>
> > > >> AnjLab Team
> > > >> http://anjlab.com
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Yunhua Sang <yu...@gmail.com>.
Can checksums-in-URL be disabled or provide a default asset path to not
apply it? I knew some heavy traffic sites are using Ngix to serve the
static assets, and only send requests for dynamic contents to Java
applications, this way won't work if the checksum is in the URL.
On Tue, Apr 9, 2013 at 2:43 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> On Tue, Apr 9, 2013 at 9:57 AM, Barry Books
> <trsvax@gmail.com<javascript:_e({}, 'cvml', 'trsvax@gmail.com');>
> > wrote:
>
> > When I tried to integrate the Amazon CDN with Tapestry the version in the
> > URL was a constant problem. The other issue is the zipped vs unzipped
> > assets. Tapestry uses the same URL for both but you can't do that with
> > Amazons CDN. You need two files.
>
>
> Interesting. That's something that could be addressed, it just
> never occurred to me that it was a problem. It's a pain though ... it means
> that anytime we write an Asset URL that *could* be compressed (JavaScript,
> CSS ... but not images) then we have to decide whether to write the URL for
> the compressed version or the uncompressed version.
>
> In the current implementation, we make that decision based on the request
> that asks for the asset, and send back the normal or compressed content at
> that point.
>
>
> > This will also be a problem with caching by ETag since compressed and
> > uncompressed assets will have different ETags. I think processing the
> CSS
> > is likely to also cause CDN problems.
> >
>
> Currently, we use the same ETag for both the compressed and the
> uncompressed version. I can see that this may be an issue with regards to
> caching and CDN ... a client may request the uncompressed version and get a
> GZIP stream unexpectedly.
>
> GWT uses the hash in asset urls and it seems to work fine. It also used
> > nocache in the URL to specify the URL is not cached. This can be useful
> > under some circumstances.
> >
>
> I can see that as well.
>
>
> >
> > On Apr 9, 2013, at 11:37 AM, Howard Lewis Ship <hlship@gmail.com<javascript:_e({},
> 'cvml', 'hlship@gmail.com');>>
> > wrote:
> >
> > > In 5.4-alpha-3, Tapestry parsers CSS and converts url() references into
> > > absolute paths that include the asset checksum.
> > >
> > > There may also be the option to inline small assets directly into the
> > > stylesheet.
> > >
> > >
> > > On Tue, Apr 9, 2013 at 6:26 AM, Barry Books <trsvax@gmail.com<javascript:_e({},
> 'cvml', 'trsvax@gmail.com');>>
> > wrote:
> > >
> > >> After being bitten by APPLICATION_VERSION I switched to this
> > >>
> > >> configuration.override(SymbolConstants.APPLICATION_VERSION,
> > >> *new*Date().getTime());
> > >>
> > >>
> > >> This way on my development machine I get a new version every restart
> > and on
> > >> my production machine on every deploy.
> > >>
> > >>
> > >> That said I think the hash of the object in the URL and a never
> expires
> > >> header is the way to handle this. The only problem I can think of is
> > assets
> > >> in style sheets. I would say the solution to that problem lookup the
> > asset
> > >> with the hashed url and return the object with a never expires header.
> > If
> > >> there is no hash just return the object without the header. This makes
> > it
> > >> easy to use assets in stylesheets. If you want to solve the caching
> > problem
> > >> just override (or declare) the style in the Layout component and use
> the
> > >> asset like this:
> > >>
> > >>
> > >> <style>
> > >>
> > >> .navbar-fixed-top {
> > >>
> > >> xheight: 64px;
> > >>
> > >> background-position: 0px 40px;
> > >>
> > >> xbackground-image: url('${context:/images/top-background.jpg}');
> > >>
> > >> xbackground-repeat: repeat-x;
> > >>
> > >> }
> > >>
> > >> </style>
> > >
> > >
> > >
> > > --
> > > 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<javascript:_e({},
> 'cvml', 'dev-unsubscribe@tapestry.apache.org');>
> > For additional commands, e-mail: dev-help@tapestry.apache.org<javascript:_e({},
> 'cvml', '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
>
>
> --
> 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
>
Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Tue, Apr 9, 2013 at 9:57 AM, Barry Books
<trsvax@gmail.com<javascript:_e({}, 'cvml', 'trsvax@gmail.com');>
> wrote:
> When I tried to integrate the Amazon CDN with Tapestry the version in the
> URL was a constant problem. The other issue is the zipped vs unzipped
> assets. Tapestry uses the same URL for both but you can't do that with
> Amazons CDN. You need two files.
Interesting. That's something that could be addressed, it just
never occurred to me that it was a problem. It's a pain though ... it means
that anytime we write an Asset URL that *could* be compressed (JavaScript,
CSS ... but not images) then we have to decide whether to write the URL for
the compressed version or the uncompressed version.
In the current implementation, we make that decision based on the request
that asks for the asset, and send back the normal or compressed content at
that point.
> This will also be a problem with caching by ETag since compressed and
> uncompressed assets will have different ETags. I think processing the CSS
> is likely to also cause CDN problems.
>
Currently, we use the same ETag for both the compressed and the
uncompressed version. I can see that this may be an issue with regards to
caching and CDN ... a client may request the uncompressed version and get a
GZIP stream unexpectedly.
GWT uses the hash in asset urls and it seems to work fine. It also used
> nocache in the URL to specify the URL is not cached. This can be useful
> under some circumstances.
>
I can see that as well.
>
> On Apr 9, 2013, at 11:37 AM, Howard Lewis Ship <hlship@gmail.com<javascript:_e({}, 'cvml', 'hlship@gmail.com');>>
> wrote:
>
> > In 5.4-alpha-3, Tapestry parsers CSS and converts url() references into
> > absolute paths that include the asset checksum.
> >
> > There may also be the option to inline small assets directly into the
> > stylesheet.
> >
> >
> > On Tue, Apr 9, 2013 at 6:26 AM, Barry Books <trsvax@gmail.com<javascript:_e({}, 'cvml', 'trsvax@gmail.com');>>
> wrote:
> >
> >> After being bitten by APPLICATION_VERSION I switched to this
> >>
> >> configuration.override(SymbolConstants.APPLICATION_VERSION,
> >> *new*Date().getTime());
> >>
> >>
> >> This way on my development machine I get a new version every restart
> and on
> >> my production machine on every deploy.
> >>
> >>
> >> That said I think the hash of the object in the URL and a never expires
> >> header is the way to handle this. The only problem I can think of is
> assets
> >> in style sheets. I would say the solution to that problem lookup the
> asset
> >> with the hashed url and return the object with a never expires header.
> If
> >> there is no hash just return the object without the header. This makes
> it
> >> easy to use assets in stylesheets. If you want to solve the caching
> problem
> >> just override (or declare) the style in the Layout component and use the
> >> asset like this:
> >>
> >>
> >> <style>
> >>
> >> .navbar-fixed-top {
> >>
> >> xheight: 64px;
> >>
> >> background-position: 0px 40px;
> >>
> >> xbackground-image: url('${context:/images/top-background.jpg}');
> >>
> >> xbackground-repeat: repeat-x;
> >>
> >> }
> >>
> >> </style>
> >
> >
> >
> > --
> > 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<javascript:_e({}, 'cvml', 'dev-unsubscribe@tapestry.apache.org');>
> For additional commands, e-mail: dev-help@tapestry.apache.org<javascript:_e({}, 'cvml', '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
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Barry Books <tr...@gmail.com>.
When I tried to integrate the Amazon CDN with Tapestry the version in the URL was a constant problem. The other issue is the zipped vs unzipped assets. Tapestry uses the same URL for both but you can't do that with Amazons CDN. You need two files. This will also be a problem with caching by ETag since compressed and uncompressed assets will have different ETags. I think processing the CSS is likely to also cause CDN problems.
GWT uses the hash in asset urls and it seems to work fine. It also used nocache in the URL to specify the URL is not cached. This can be useful under some circumstances.
On Apr 9, 2013, at 11:37 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> In 5.4-alpha-3, Tapestry parsers CSS and converts url() references into
> absolute paths that include the asset checksum.
>
> There may also be the option to inline small assets directly into the
> stylesheet.
>
>
> On Tue, Apr 9, 2013 at 6:26 AM, Barry Books <tr...@gmail.com> wrote:
>
>> After being bitten by APPLICATION_VERSION I switched to this
>>
>> configuration.override(SymbolConstants.APPLICATION_VERSION,
>> *new*Date().getTime());
>>
>>
>> This way on my development machine I get a new version every restart and on
>> my production machine on every deploy.
>>
>>
>> That said I think the hash of the object in the URL and a never expires
>> header is the way to handle this. The only problem I can think of is assets
>> in style sheets. I would say the solution to that problem lookup the asset
>> with the hashed url and return the object with a never expires header. If
>> there is no hash just return the object without the header. This makes it
>> easy to use assets in stylesheets. If you want to solve the caching problem
>> just override (or declare) the style in the Layout component and use the
>> asset like this:
>>
>>
>> <style>
>>
>> .navbar-fixed-top {
>>
>> xheight: 64px;
>>
>> background-position: 0px 40px;
>>
>> xbackground-image: url('${context:/images/top-background.jpg}');
>>
>> xbackground-repeat: repeat-x;
>>
>> }
>>
>> </style>
>
>
>
> --
> 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: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
In 5.4-alpha-3, Tapestry parsers CSS and converts url() references into
absolute paths that include the asset checksum.
There may also be the option to inline small assets directly into the
stylesheet.
On Tue, Apr 9, 2013 at 6:26 AM, Barry Books <tr...@gmail.com> wrote:
> After being bitten by APPLICATION_VERSION I switched to this
>
> configuration.override(SymbolConstants.APPLICATION_VERSION,
> *new*Date().getTime());
>
>
> This way on my development machine I get a new version every restart and on
> my production machine on every deploy.
>
>
> That said I think the hash of the object in the URL and a never expires
> header is the way to handle this. The only problem I can think of is assets
> in style sheets. I would say the solution to that problem lookup the asset
> with the hashed url and return the object with a never expires header. If
> there is no hash just return the object without the header. This makes it
> easy to use assets in stylesheets. If you want to solve the caching problem
> just override (or declare) the style in the Layout component and use the
> asset like this:
>
>
> <style>
>
> .navbar-fixed-top {
>
> xheight: 64px;
>
> background-position: 0px 40px;
>
> xbackground-image: url('${context:/images/top-background.jpg}');
>
> xbackground-repeat: repeat-x;
>
> }
>
> </style>
>
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think having a special "matches anything" checksum value (perhaps "-"?)
might be a good idea from an integration point of view. Again, for
anything that originates inside Tapestry, Tapestry will build the correct
URL.
On Tue, Apr 9, 2013 at 9:18 AM, Barry Books <tr...@gmail.com> wrote:
> I'm not a big fan of the release in the URL for three reasons
>
> 1 it causes problems in development because things change but the URL does
> not
>
> 2 it causes all resources to become invalid with a release even if they do
> not change. The more often you release the bigger the problem
>
> 3. It complicates CDN integration because all the assets paths change
> every release
>
> Using a hash as part of the URL
>
> /assets/myapp/hash/.../name solves these but makes the URL difficult to
> predict. Adding
> /assets/myapp/nocache/.../name
>
> Makes it possible to predict the name in style sheets if needed and CSS
> rules allow this to be overridden in the layout if you want the performance
> increase. The ETag could also be used here so the nocache asset could
> return a not modified
>
> On Apr 9, 2013, at 9:46 AM, Ivan Khalopik <ik...@gmail.com> wrote:
>
> > In my opinion the best practice is to use ETag in addition to application
> > version folder. So the first level of asset caching is by path, e.g.
> > /assets/myapp/1.0.0/... When we deploy a new app version, this path is
> > changed and browser forces new assets retrieval. If application version
> is
> > not changed, we have the same path for assets and they are cached by
> > browser until expired. But we can also reduce the traffic even if app
> > version is changed or browser cache is expired. If we have the second
> level
> > of cache using ETag. If asset checksum is changed we will return the
> whole
> > asset content, or just 304 otherwise.
> >
> > So, application version folder reduces request count to those that are
> not
> > cached for current app version, ETag reduces the rest of traffic if asset
> > checksum is not changed.
> >
> >
> >
> >
> > On Tue, Apr 9, 2013 at 4:39 PM, Dmitry Gusev <dm...@gmail.com>
> wrote:
> >
> >> Barry,
> >>
> >> no need to pass current date as application version, because if you
> don't
> >> supply any defaults then
> >> tapestry will generate random version for you.
> >>
> >> But this may have some limitations if you're running in a clustered
> >> environment.
> >>
> >> Also your clients will get new assets every time you restart your
> server.
> >>
> >> See this:
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3cAANLkTinZ4uKJNG-zom8T86RY-mRW7st7e9EUFHKVVLqf@mail.gmail.com%3e
> >>
> >>
> >> On Tue, Apr 9, 2013 at 5:26 PM, Barry Books <tr...@gmail.com> wrote:
> >>
> >>> After being bitten by APPLICATION_VERSION I switched to this
> >>>
> >>> configuration.override(SymbolConstants.APPLICATION_VERSION,
> >>> *new*Date().getTime());
> >>>
> >>>
> >>> This way on my development machine I get a new version every restart
> and
> >> on
> >>> my production machine on every deploy.
> >>>
> >>>
> >>> That said I think the hash of the object in the URL and a never expires
> >>> header is the way to handle this. The only problem I can think of is
> >> assets
> >>> in style sheets. I would say the solution to that problem lookup the
> >> asset
> >>> with the hashed url and return the object with a never expires header.
> If
> >>> there is no hash just return the object without the header. This makes
> it
> >>> easy to use assets in stylesheets. If you want to solve the caching
> >> problem
> >>> just override (or declare) the style in the Layout component and use
> the
> >>> asset like this:
> >>>
> >>>
> >>> <style>
> >>>
> >>> .navbar-fixed-top {
> >>>
> >>> xheight: 64px;
> >>>
> >>> background-position: 0px 40px;
> >>>
> >>> xbackground-image: url('${context:/images/top-background.jpg}');
> >>>
> >>> xbackground-repeat: repeat-x;
> >>>
> >>> }
> >>>
> >>> </style>
> >>
> >>
> >>
> >> --
> >> Dmitry Gusev
> >>
> >> AnjLab Team
> >> http://anjlab.com
> >
> >
> >
> > --
> > BR
> > Ivan
>
> ---------------------------------------------------------------------
> 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
Re: Coming soon: per-Asset checkums in URLs
Posted by Barry Books <tr...@gmail.com>.
I'm not a big fan of the release in the URL for three reasons
1 it causes problems in development because things change but the URL does not
2 it causes all resources to become invalid with a release even if they do not change. The more often you release the bigger the problem
3. It complicates CDN integration because all the assets paths change every release
Using a hash as part of the URL
/assets/myapp/hash/.../name solves these but makes the URL difficult to predict. Adding
/assets/myapp/nocache/.../name
Makes it possible to predict the name in style sheets if needed and CSS rules allow this to be overridden in the layout if you want the performance increase. The ETag could also be used here so the nocache asset could return a not modified
On Apr 9, 2013, at 9:46 AM, Ivan Khalopik <ik...@gmail.com> wrote:
> In my opinion the best practice is to use ETag in addition to application
> version folder. So the first level of asset caching is by path, e.g.
> /assets/myapp/1.0.0/... When we deploy a new app version, this path is
> changed and browser forces new assets retrieval. If application version is
> not changed, we have the same path for assets and they are cached by
> browser until expired. But we can also reduce the traffic even if app
> version is changed or browser cache is expired. If we have the second level
> of cache using ETag. If asset checksum is changed we will return the whole
> asset content, or just 304 otherwise.
>
> So, application version folder reduces request count to those that are not
> cached for current app version, ETag reduces the rest of traffic if asset
> checksum is not changed.
>
>
>
>
> On Tue, Apr 9, 2013 at 4:39 PM, Dmitry Gusev <dm...@gmail.com> wrote:
>
>> Barry,
>>
>> no need to pass current date as application version, because if you don't
>> supply any defaults then
>> tapestry will generate random version for you.
>>
>> But this may have some limitations if you're running in a clustered
>> environment.
>>
>> Also your clients will get new assets every time you restart your server.
>>
>> See this:
>>
>> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3cAANLkTinZ4uKJNG-zom8T86RY-mRW7st7e9EUFHKVVLqf@mail.gmail.com%3e
>>
>>
>> On Tue, Apr 9, 2013 at 5:26 PM, Barry Books <tr...@gmail.com> wrote:
>>
>>> After being bitten by APPLICATION_VERSION I switched to this
>>>
>>> configuration.override(SymbolConstants.APPLICATION_VERSION,
>>> *new*Date().getTime());
>>>
>>>
>>> This way on my development machine I get a new version every restart and
>> on
>>> my production machine on every deploy.
>>>
>>>
>>> That said I think the hash of the object in the URL and a never expires
>>> header is the way to handle this. The only problem I can think of is
>> assets
>>> in style sheets. I would say the solution to that problem lookup the
>> asset
>>> with the hashed url and return the object with a never expires header. If
>>> there is no hash just return the object without the header. This makes it
>>> easy to use assets in stylesheets. If you want to solve the caching
>> problem
>>> just override (or declare) the style in the Layout component and use the
>>> asset like this:
>>>
>>>
>>> <style>
>>>
>>> .navbar-fixed-top {
>>>
>>> xheight: 64px;
>>>
>>> background-position: 0px 40px;
>>>
>>> xbackground-image: url('${context:/images/top-background.jpg}');
>>>
>>> xbackground-repeat: repeat-x;
>>>
>>> }
>>>
>>> </style>
>>
>>
>>
>> --
>> Dmitry Gusev
>>
>> AnjLab Team
>> http://anjlab.com
>
>
>
> --
> BR
> Ivan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Coming soon: per-Asset checkums in URLs
Posted by Ivan Khalopik <ik...@gmail.com>.
In my opinion the best practice is to use ETag in addition to application
version folder. So the first level of asset caching is by path, e.g.
/assets/myapp/1.0.0/... When we deploy a new app version, this path is
changed and browser forces new assets retrieval. If application version is
not changed, we have the same path for assets and they are cached by
browser until expired. But we can also reduce the traffic even if app
version is changed or browser cache is expired. If we have the second level
of cache using ETag. If asset checksum is changed we will return the whole
asset content, or just 304 otherwise.
So, application version folder reduces request count to those that are not
cached for current app version, ETag reduces the rest of traffic if asset
checksum is not changed.
On Tue, Apr 9, 2013 at 4:39 PM, Dmitry Gusev <dm...@gmail.com> wrote:
> Barry,
>
> no need to pass current date as application version, because if you don't
> supply any defaults then
> tapestry will generate random version for you.
>
> But this may have some limitations if you're running in a clustered
> environment.
>
> Also your clients will get new assets every time you restart your server.
>
> See this:
>
> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3cAANLkTinZ4uKJNG-zom8T86RY-mRW7st7e9EUFHKVVLqf@mail.gmail.com%3e
>
>
> On Tue, Apr 9, 2013 at 5:26 PM, Barry Books <tr...@gmail.com> wrote:
>
> > After being bitten by APPLICATION_VERSION I switched to this
> >
> > configuration.override(SymbolConstants.APPLICATION_VERSION,
> > *new*Date().getTime());
> >
> >
> > This way on my development machine I get a new version every restart and
> on
> > my production machine on every deploy.
> >
> >
> > That said I think the hash of the object in the URL and a never expires
> > header is the way to handle this. The only problem I can think of is
> assets
> > in style sheets. I would say the solution to that problem lookup the
> asset
> > with the hashed url and return the object with a never expires header. If
> > there is no hash just return the object without the header. This makes it
> > easy to use assets in stylesheets. If you want to solve the caching
> problem
> > just override (or declare) the style in the Layout component and use the
> > asset like this:
> >
> >
> > <style>
> >
> > .navbar-fixed-top {
> >
> > xheight: 64px;
> >
> > background-position: 0px 40px;
> >
> > xbackground-image: url('${context:/images/top-background.jpg}');
> >
> > xbackground-repeat: repeat-x;
> >
> > }
> >
> > </style>
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
BR
Ivan
Re: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
Again, in the coming 5.4-alpha-3, application version is informational
only, which bypasses the issues that Barry is concerned about.
On Tue, Apr 9, 2013 at 9:38 AM, Barry Books <tr...@gmail.com> wrote:
> I could just use the default but this way I know what it's doing. I also
> release more than I restart so that does not matter to me. Clustering would
> be a problem
>
> On Apr 9, 2013, at 8:39 AM, Dmitry Gusev <dm...@gmail.com> wrote:
>
> > Barry,
> >
> > no need to pass current date as application version, because if you don't
> > supply any defaults then
> > tapestry will generate random version for you.
> >
> > But this may have some limitations if you're running in a clustered
> > environment.
> >
> > Also your clients will get new assets every time you restart your server.
> >
> > See this:
> >
> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3cAANLkTinZ4uKJNG-zom8T86RY-mRW7st7e9EUFHKVVLqf@mail.gmail.com%3e
> >
> >
> > On Tue, Apr 9, 2013 at 5:26 PM, Barry Books <tr...@gmail.com> wrote:
> >
> >> After being bitten by APPLICATION_VERSION I switched to this
> >>
> >> configuration.override(SymbolConstants.APPLICATION_VERSION,
> >> *new*Date().getTime());
> >>
> >>
> >> This way on my development machine I get a new version every restart
> and on
> >> my production machine on every deploy.
> >>
> >>
> >> That said I think the hash of the object in the URL and a never expires
> >> header is the way to handle this. The only problem I can think of is
> assets
> >> in style sheets. I would say the solution to that problem lookup the
> asset
> >> with the hashed url and return the object with a never expires header.
> If
> >> there is no hash just return the object without the header. This makes
> it
> >> easy to use assets in stylesheets. If you want to solve the caching
> problem
> >> just override (or declare) the style in the Layout component and use the
> >> asset like this:
> >>
> >>
> >> <style>
> >>
> >> .navbar-fixed-top {
> >>
> >> xheight: 64px;
> >>
> >> background-position: 0px 40px;
> >>
> >> xbackground-image: url('${context:/images/top-background.jpg}');
> >>
> >> xbackground-repeat: repeat-x;
> >>
> >> }
> >>
> >> </style>
> >
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
>
> ---------------------------------------------------------------------
> 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
Re: Coming soon: per-Asset checkums in URLs
Posted by Barry Books <tr...@gmail.com>.
I could just use the default but this way I know what it's doing. I also release more than I restart so that does not matter to me. Clustering would be a problem
On Apr 9, 2013, at 8:39 AM, Dmitry Gusev <dm...@gmail.com> wrote:
> Barry,
>
> no need to pass current date as application version, because if you don't
> supply any defaults then
> tapestry will generate random version for you.
>
> But this may have some limitations if you're running in a clustered
> environment.
>
> Also your clients will get new assets every time you restart your server.
>
> See this:
> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3cAANLkTinZ4uKJNG-zom8T86RY-mRW7st7e9EUFHKVVLqf@mail.gmail.com%3e
>
>
> On Tue, Apr 9, 2013 at 5:26 PM, Barry Books <tr...@gmail.com> wrote:
>
>> After being bitten by APPLICATION_VERSION I switched to this
>>
>> configuration.override(SymbolConstants.APPLICATION_VERSION,
>> *new*Date().getTime());
>>
>>
>> This way on my development machine I get a new version every restart and on
>> my production machine on every deploy.
>>
>>
>> That said I think the hash of the object in the URL and a never expires
>> header is the way to handle this. The only problem I can think of is assets
>> in style sheets. I would say the solution to that problem lookup the asset
>> with the hashed url and return the object with a never expires header. If
>> there is no hash just return the object without the header. This makes it
>> easy to use assets in stylesheets. If you want to solve the caching problem
>> just override (or declare) the style in the Layout component and use the
>> asset like this:
>>
>>
>> <style>
>>
>> .navbar-fixed-top {
>>
>> xheight: 64px;
>>
>> background-position: 0px 40px;
>>
>> xbackground-image: url('${context:/images/top-background.jpg}');
>>
>> xbackground-repeat: repeat-x;
>>
>> }
>>
>> </style>
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Coming soon: per-Asset checkums in URLs
Posted by Dmitry Gusev <dm...@gmail.com>.
Barry,
no need to pass current date as application version, because if you don't
supply any defaults then
tapestry will generate random version for you.
But this may have some limitations if you're running in a clustered
environment.
Also your clients will get new assets every time you restart your server.
See this:
http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3cAANLkTinZ4uKJNG-zom8T86RY-mRW7st7e9EUFHKVVLqf@mail.gmail.com%3e
On Tue, Apr 9, 2013 at 5:26 PM, Barry Books <tr...@gmail.com> wrote:
> After being bitten by APPLICATION_VERSION I switched to this
>
> configuration.override(SymbolConstants.APPLICATION_VERSION,
> *new*Date().getTime());
>
>
> This way on my development machine I get a new version every restart and on
> my production machine on every deploy.
>
>
> That said I think the hash of the object in the URL and a never expires
> header is the way to handle this. The only problem I can think of is assets
> in style sheets. I would say the solution to that problem lookup the asset
> with the hashed url and return the object with a never expires header. If
> there is no hash just return the object without the header. This makes it
> easy to use assets in stylesheets. If you want to solve the caching problem
> just override (or declare) the style in the Layout component and use the
> asset like this:
>
>
> <style>
>
> .navbar-fixed-top {
>
> xheight: 64px;
>
> background-position: 0px 40px;
>
> xbackground-image: url('${context:/images/top-background.jpg}');
>
> xbackground-repeat: repeat-x;
>
> }
>
> </style>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Coming soon: per-Asset checkums in URLs
Posted by Barry Books <tr...@gmail.com>.
After being bitten by APPLICATION_VERSION I switched to this
configuration.override(SymbolConstants.APPLICATION_VERSION,
*new*Date().getTime());
This way on my development machine I get a new version every restart and on
my production machine on every deploy.
That said I think the hash of the object in the URL and a never expires
header is the way to handle this. The only problem I can think of is assets
in style sheets. I would say the solution to that problem lookup the asset
with the hashed url and return the object with a never expires header. If
there is no hash just return the object without the header. This makes it
easy to use assets in stylesheets. If you want to solve the caching problem
just override (or declare) the style in the Layout component and use the
asset like this:
<style>
.navbar-fixed-top {
xheight: 64px;
background-position: 0px 40px;
xbackground-image: url('${context:/images/top-background.jpg}');
xbackground-repeat: repeat-x;
}
</style>
Re: Coming soon: per-Asset checkums in URLs
Posted by Kalle Korhonen <ka...@gmail.com>.
I agree with Bob and Dmitry. Not that ETags will increase the absolute
number of requests but the issue is it won't reduce them. We should always
use the far-future headers if we possible. Setting the application version
is one of the easiest things you can do - I'd go as far as saying you are
doing something wrong if you can't automatically increment the application
version every time you are deploying.
Kalle
On Tue, Apr 9, 2013 at 12:21 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> I agree with Bob, isn't the whole idea of asset checksums and far-future
> expire
> headers was to reduce number of HTTP requests?
>
> Whats the advantage of ETags then?
> I bet the majority of assets for which HTTP 304 Not Modified would
> be returned would weight pretty much the same (in bytes) as returned 304
> response.
>
> I'd normally use Etag when I had to implement some transactional state in
> some REST conversation.
>
> Keep in mind that, for instance, on AppEngine (or name any other cloud
> provider) such request could cost much
> more that just returning 304 -- AppEngine could start a new instance of
> application to serve this request.
> So I think for assets the main goal is reducing number of requests, but not
> optimizing the payload.
>
>
> Btw,
>
> > I've generally assumed that URLs with query
> > parameters are less likely to be cached in the browser, or served
> properly
> > by intermediate (reverse proxy) servers, but I haven't done the research.
>
> I noticed you've integrated checksums into the path of URL, not as GET
> parameters...
>
> Do you have any reason for this? Done any research?
> Because I'm seeing this pattern with GET parameters
> is widely abopted on the web and it works good.
>
>
> On Tue, Apr 9, 2013 at 5:43 AM, Bob Harner <bo...@gmail.com> wrote:
>
> > Doesn't the switch to ETags for modules make for much chattier web apps,
> > with lots more "conditional GET" requests for JS modules coming in after
> > every page request?
> >
> > In any case, good riddance to the application version numbers.
> >
> > On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hl...@gmail.com>
> > wrote:
> >
> > > With the ETag support in place, there's no longer any need for the
> module
> > > asset URLs to have a checksum or version number; they are no longer
> > given a
> > > far-future expires header.
> > >
> > > URLs (by default) look like "/modules/t5/core/dom.js" (where the module
> > > name is t5/core/dom).
> > >
> > > The application version number is no longer used in any URLs; it now
> > exists
> > > just for documentation purposes (its written to the console at startup
> > and
> > > in the exception report). This is good news, because you could screw
> > > yourself by deploying your application and NOT changing the version
> > number
> > > (in 5.3.6).
> > >
> > > Very happy about this ... next up, thoughts on cometd/server-push
> > support?
> > >
> > >
> > >
> > > On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hlship@gmail.com
> > > >wrote:
> > >
> > > >
> > > >
> > > > On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <
> dmitry.gusev@gmail.com
> > > >wrote:
> > > >
> > > >> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <
> hlship@gmail.com
> > > >> >wrote:
> > > >>
> > > >> > I've been working, a few hours a week, on getting per-asset
> > checksums
> > > >> into
> > > >> > URLs.
> > > >> >
> > > >> > Some parts of this have been a challenge to accomplish without
> > > >> completely
> > > >> > breaking the Asset interface and a bunch of public services.
> > > >> >
> > > >> > For ordinary assets, it's pretty easy ... but for aggregated
> > > JavaScript
> > > >> > libraries its been a pain that's affected a bunch of stuff.
> > > >> >
> > > >> > CSS files are now rewritten, since relative URLs will be broken by
> > the
> > > >> > addition of the checksum. I have a first (but not final) pass at
> > this,
> > > >>
> > > >> where url() patterns in the CSS are converted into complete paths.
> > This
> > > >> > also opens the door to CSS aggregation as well as JavaScript
> > > >> aggregation.
> > > >> >
> > > >> >
> > > >> It depends on where you put the checksum.
> > > >> If you put it as a GET parameter - then no relative URLs will be
> > broken.
> > > >>
> > > >> Have you read my blog post about Tapestry5 checksums in assets?
> > > >>
> > > >>
> > >
> >
> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
> > > >
> > > >
> > > > I'll read this shortly. I've generally assumed that URLs with query
> > > > parameters are less likely to be cached in the browser, or served
> > > properly
> > > > by intermediate (reverse proxy) servers, but I haven't done the
> > research.
> > > >
> > > >
> > > >>
> > > >>
> > > >> > I still don't have a great solution for JavaScript modules;
> > > >> RequireJS/AMD
> > > >> > expect that there's a common root folder name (such as
> > > >> "/assets/modules/"),
> > > >> > and module "a/b" is simply "*root*/a/b.js". For individual
> modules,
> > > you
> > > >> can
> > > >> > write your own overrides. In fact, Tapestry has to strip off the
> > > ".js'
> > > >> > part (which is hard-wired by RequireJS) because the actual
> > server-side
> > > >> > resource could be CoffeeScript or some other language that
> compiles
> > to
> > > >> > JavaScript.
> > > >> >
> > > >> > Short of iterating all server-side module files and writing a
> > > RequireJS
> > > >> > config for each one (mapping each name to a URL with an embedded
> > > >> checksum),
> > > >> > there isn't a great solution. Alternately, something could
> iterate
> > > all
> > > >> the
> > > >> > server-side modules and built a composite checksum, but there are
> at
> > > >> least
> > > >> > a couple of virtual modules generated at runtime (and locale
> > specific
> > > >> for
> > > >> > extra kicks).
> > > >> >
> > > >> > Modules may have to stay on the 5.3 approach: using the
> application
> > > >> version
> > > >> > number for everything.
> > > >> >
> > > >> > Finding the sweet spot where assets of all kinds (CSS, JavaScript
> > > >> > libraries, JavaScript modules, etc.) can be changed freely and the
> > > URLs
> > > >> > automatically reflect the actual content (that is, include a
> > checksum
> > > of
> > > >> > that content) for ideal client-side caching ... may simply be out
> of
> > > >> reach.
> > > >> >
> > > >> > Perhaps for modules we should use an alternate approach based on
> > > ETags (
> > > >> > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there
> > > would
> > > >> > not
> > > >> > need to be any version number of checksum in a module URL, but
> > clients
> > > >> > would request the module content more often (and based on ETag,
> > would
> > > >> often
> > > >> > get a 304 Not Modified). I would prefer to see a URL that changes
> > > when
> > > >> the
> > > >> > content changes (which prevents the request entirely).
> > > >> >
> > > >> > --
> > > >> > 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
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Dmitry Gusev
> > > >>
> > > >> AnjLab Team
> > > >> http://anjlab.com
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
Re: Coming soon: per-Asset checkums in URLs
Posted by Dmitry Gusev <dm...@gmail.com>.
I agree with Bob, isn't the whole idea of asset checksums and far-future
expire
headers was to reduce number of HTTP requests?
Whats the advantage of ETags then?
I bet the majority of assets for which HTTP 304 Not Modified would
be returned would weight pretty much the same (in bytes) as returned 304
response.
I'd normally use Etag when I had to implement some transactional state in
some REST conversation.
Keep in mind that, for instance, on AppEngine (or name any other cloud
provider) such request could cost much
more that just returning 304 -- AppEngine could start a new instance of
application to serve this request.
So I think for assets the main goal is reducing number of requests, but not
optimizing the payload.
Btw,
> I've generally assumed that URLs with query
> parameters are less likely to be cached in the browser, or served properly
> by intermediate (reverse proxy) servers, but I haven't done the research.
I noticed you've integrated checksums into the path of URL, not as GET
parameters...
Do you have any reason for this? Done any research?
Because I'm seeing this pattern with GET parameters
is widely abopted on the web and it works good.
On Tue, Apr 9, 2013 at 5:43 AM, Bob Harner <bo...@gmail.com> wrote:
> Doesn't the switch to ETags for modules make for much chattier web apps,
> with lots more "conditional GET" requests for JS modules coming in after
> every page request?
>
> In any case, good riddance to the application version numbers.
>
> On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> > With the ETag support in place, there's no longer any need for the module
> > asset URLs to have a checksum or version number; they are no longer
> given a
> > far-future expires header.
> >
> > URLs (by default) look like "/modules/t5/core/dom.js" (where the module
> > name is t5/core/dom).
> >
> > The application version number is no longer used in any URLs; it now
> exists
> > just for documentation purposes (its written to the console at startup
> and
> > in the exception report). This is good news, because you could screw
> > yourself by deploying your application and NOT changing the version
> number
> > (in 5.3.6).
> >
> > Very happy about this ... next up, thoughts on cometd/server-push
> support?
> >
> >
> >
> > On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hlship@gmail.com
> > >wrote:
> >
> > >
> > >
> > > On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> > >wrote:
> > >
> > >> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hlship@gmail.com
> > >> >wrote:
> > >>
> > >> > I've been working, a few hours a week, on getting per-asset
> checksums
> > >> into
> > >> > URLs.
> > >> >
> > >> > Some parts of this have been a challenge to accomplish without
> > >> completely
> > >> > breaking the Asset interface and a bunch of public services.
> > >> >
> > >> > For ordinary assets, it's pretty easy ... but for aggregated
> > JavaScript
> > >> > libraries its been a pain that's affected a bunch of stuff.
> > >> >
> > >> > CSS files are now rewritten, since relative URLs will be broken by
> the
> > >> > addition of the checksum. I have a first (but not final) pass at
> this,
> > >>
> > >> where url() patterns in the CSS are converted into complete paths.
> This
> > >> > also opens the door to CSS aggregation as well as JavaScript
> > >> aggregation.
> > >> >
> > >> >
> > >> It depends on where you put the checksum.
> > >> If you put it as a GET parameter - then no relative URLs will be
> broken.
> > >>
> > >> Have you read my blog post about Tapestry5 checksums in assets?
> > >>
> > >>
> >
> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
> > >
> > >
> > > I'll read this shortly. I've generally assumed that URLs with query
> > > parameters are less likely to be cached in the browser, or served
> > properly
> > > by intermediate (reverse proxy) servers, but I haven't done the
> research.
> > >
> > >
> > >>
> > >>
> > >> > I still don't have a great solution for JavaScript modules;
> > >> RequireJS/AMD
> > >> > expect that there's a common root folder name (such as
> > >> "/assets/modules/"),
> > >> > and module "a/b" is simply "*root*/a/b.js". For individual modules,
> > you
> > >> can
> > >> > write your own overrides. In fact, Tapestry has to strip off the
> > ".js'
> > >> > part (which is hard-wired by RequireJS) because the actual
> server-side
> > >> > resource could be CoffeeScript or some other language that compiles
> to
> > >> > JavaScript.
> > >> >
> > >> > Short of iterating all server-side module files and writing a
> > RequireJS
> > >> > config for each one (mapping each name to a URL with an embedded
> > >> checksum),
> > >> > there isn't a great solution. Alternately, something could iterate
> > all
> > >> the
> > >> > server-side modules and built a composite checksum, but there are at
> > >> least
> > >> > a couple of virtual modules generated at runtime (and locale
> specific
> > >> for
> > >> > extra kicks).
> > >> >
> > >> > Modules may have to stay on the 5.3 approach: using the application
> > >> version
> > >> > number for everything.
> > >> >
> > >> > Finding the sweet spot where assets of all kinds (CSS, JavaScript
> > >> > libraries, JavaScript modules, etc.) can be changed freely and the
> > URLs
> > >> > automatically reflect the actual content (that is, include a
> checksum
> > of
> > >> > that content) for ideal client-side caching ... may simply be out of
> > >> reach.
> > >> >
> > >> > Perhaps for modules we should use an alternate approach based on
> > ETags (
> > >> > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there
> > would
> > >> > not
> > >> > need to be any version number of checksum in a module URL, but
> clients
> > >> > would request the module content more often (and based on ETag,
> would
> > >> often
> > >> > get a 304 Not Modified). I would prefer to see a URL that changes
> > when
> > >> the
> > >> > content changes (which prevents the request entirely).
> > >> >
> > >> > --
> > >> > 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
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Dmitry Gusev
> > >>
> > >> AnjLab Team
> > >> http://anjlab.com
> > >>
> > >
> > >
> > >
> > > --
> > > 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
> > >
> >
> >
> >
> > --
> > 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
> >
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
There will be some additional "chatter"; short fast requests. I will look
to offset that by allowing JavaScriptStacks to import modules as well as
libraries.
On Mon, Apr 8, 2013 at 6:43 PM, Bob Harner <bo...@gmail.com> wrote:
> Doesn't the switch to ETags for modules make for much chattier web apps,
> with lots more "conditional GET" requests for JS modules coming in after
> every page request?
>
> In any case, good riddance to the application version numbers.
>
> On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> > With the ETag support in place, there's no longer any need for the module
> > asset URLs to have a checksum or version number; they are no longer
> given a
> > far-future expires header.
> >
> > URLs (by default) look like "/modules/t5/core/dom.js" (where the module
> > name is t5/core/dom).
> >
> > The application version number is no longer used in any URLs; it now
> exists
> > just for documentation purposes (its written to the console at startup
> and
> > in the exception report). This is good news, because you could screw
> > yourself by deploying your application and NOT changing the version
> number
> > (in 5.3.6).
> >
> > Very happy about this ... next up, thoughts on cometd/server-push
> support?
> >
> >
> >
> > On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hlship@gmail.com
> > >wrote:
> >
> > >
> > >
> > > On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> > >wrote:
> > >
> > >> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hlship@gmail.com
> > >> >wrote:
> > >>
> > >> > I've been working, a few hours a week, on getting per-asset
> checksums
> > >> into
> > >> > URLs.
> > >> >
> > >> > Some parts of this have been a challenge to accomplish without
> > >> completely
> > >> > breaking the Asset interface and a bunch of public services.
> > >> >
> > >> > For ordinary assets, it's pretty easy ... but for aggregated
> > JavaScript
> > >> > libraries its been a pain that's affected a bunch of stuff.
> > >> >
> > >> > CSS files are now rewritten, since relative URLs will be broken by
> the
> > >> > addition of the checksum. I have a first (but not final) pass at
> this,
> > >>
> > >> where url() patterns in the CSS are converted into complete paths.
> This
> > >> > also opens the door to CSS aggregation as well as JavaScript
> > >> aggregation.
> > >> >
> > >> >
> > >> It depends on where you put the checksum.
> > >> If you put it as a GET parameter - then no relative URLs will be
> broken.
> > >>
> > >> Have you read my blog post about Tapestry5 checksums in assets?
> > >>
> > >>
> >
> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
> > >
> > >
> > > I'll read this shortly. I've generally assumed that URLs with query
> > > parameters are less likely to be cached in the browser, or served
> > properly
> > > by intermediate (reverse proxy) servers, but I haven't done the
> research.
> > >
> > >
> > >>
> > >>
> > >> > I still don't have a great solution for JavaScript modules;
> > >> RequireJS/AMD
> > >> > expect that there's a common root folder name (such as
> > >> "/assets/modules/"),
> > >> > and module "a/b" is simply "*root*/a/b.js". For individual modules,
> > you
> > >> can
> > >> > write your own overrides. In fact, Tapestry has to strip off the
> > ".js'
> > >> > part (which is hard-wired by RequireJS) because the actual
> server-side
> > >> > resource could be CoffeeScript or some other language that compiles
> to
> > >> > JavaScript.
> > >> >
> > >> > Short of iterating all server-side module files and writing a
> > RequireJS
> > >> > config for each one (mapping each name to a URL with an embedded
> > >> checksum),
> > >> > there isn't a great solution. Alternately, something could iterate
> > all
> > >> the
> > >> > server-side modules and built a composite checksum, but there are at
> > >> least
> > >> > a couple of virtual modules generated at runtime (and locale
> specific
> > >> for
> > >> > extra kicks).
> > >> >
> > >> > Modules may have to stay on the 5.3 approach: using the application
> > >> version
> > >> > number for everything.
> > >> >
> > >> > Finding the sweet spot where assets of all kinds (CSS, JavaScript
> > >> > libraries, JavaScript modules, etc.) can be changed freely and the
> > URLs
> > >> > automatically reflect the actual content (that is, include a
> checksum
> > of
> > >> > that content) for ideal client-side caching ... may simply be out of
> > >> reach.
> > >> >
> > >> > Perhaps for modules we should use an alternate approach based on
> > ETags (
> > >> > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there
> > would
> > >> > not
> > >> > need to be any version number of checksum in a module URL, but
> clients
> > >> > would request the module content more often (and based on ETag,
> would
> > >> often
> > >> > get a 304 Not Modified). I would prefer to see a URL that changes
> > when
> > >> the
> > >> > content changes (which prevents the request entirely).
> > >> >
> > >> > --
> > >> > 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
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Dmitry Gusev
> > >>
> > >> AnjLab Team
> > >> http://anjlab.com
> > >>
> > >
> > >
> > >
> > > --
> > > 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
> > >
> >
> >
> >
> > --
> > 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
> >
>
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Bob Harner <bo...@gmail.com>.
Doesn't the switch to ETags for modules make for much chattier web apps,
with lots more "conditional GET" requests for JS modules coming in after
every page request?
In any case, good riddance to the application version numbers.
On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> With the ETag support in place, there's no longer any need for the module
> asset URLs to have a checksum or version number; they are no longer given a
> far-future expires header.
>
> URLs (by default) look like "/modules/t5/core/dom.js" (where the module
> name is t5/core/dom).
>
> The application version number is no longer used in any URLs; it now exists
> just for documentation purposes (its written to the console at startup and
> in the exception report). This is good news, because you could screw
> yourself by deploying your application and NOT changing the version number
> (in 5.3.6).
>
> Very happy about this ... next up, thoughts on cometd/server-push support?
>
>
>
> On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hlship@gmail.com
> >wrote:
>
> >
> >
> > On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >wrote:
> >
> >> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hlship@gmail.com
> >> >wrote:
> >>
> >> > I've been working, a few hours a week, on getting per-asset checksums
> >> into
> >> > URLs.
> >> >
> >> > Some parts of this have been a challenge to accomplish without
> >> completely
> >> > breaking the Asset interface and a bunch of public services.
> >> >
> >> > For ordinary assets, it's pretty easy ... but for aggregated
> JavaScript
> >> > libraries its been a pain that's affected a bunch of stuff.
> >> >
> >> > CSS files are now rewritten, since relative URLs will be broken by the
> >> > addition of the checksum. I have a first (but not final) pass at this,
> >>
> >> where url() patterns in the CSS are converted into complete paths. This
> >> > also opens the door to CSS aggregation as well as JavaScript
> >> aggregation.
> >> >
> >> >
> >> It depends on where you put the checksum.
> >> If you put it as a GET parameter - then no relative URLs will be broken.
> >>
> >> Have you read my blog post about Tapestry5 checksums in assets?
> >>
> >>
> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
> >
> >
> > I'll read this shortly. I've generally assumed that URLs with query
> > parameters are less likely to be cached in the browser, or served
> properly
> > by intermediate (reverse proxy) servers, but I haven't done the research.
> >
> >
> >>
> >>
> >> > I still don't have a great solution for JavaScript modules;
> >> RequireJS/AMD
> >> > expect that there's a common root folder name (such as
> >> "/assets/modules/"),
> >> > and module "a/b" is simply "*root*/a/b.js". For individual modules,
> you
> >> can
> >> > write your own overrides. In fact, Tapestry has to strip off the
> ".js'
> >> > part (which is hard-wired by RequireJS) because the actual server-side
> >> > resource could be CoffeeScript or some other language that compiles to
> >> > JavaScript.
> >> >
> >> > Short of iterating all server-side module files and writing a
> RequireJS
> >> > config for each one (mapping each name to a URL with an embedded
> >> checksum),
> >> > there isn't a great solution. Alternately, something could iterate
> all
> >> the
> >> > server-side modules and built a composite checksum, but there are at
> >> least
> >> > a couple of virtual modules generated at runtime (and locale specific
> >> for
> >> > extra kicks).
> >> >
> >> > Modules may have to stay on the 5.3 approach: using the application
> >> version
> >> > number for everything.
> >> >
> >> > Finding the sweet spot where assets of all kinds (CSS, JavaScript
> >> > libraries, JavaScript modules, etc.) can be changed freely and the
> URLs
> >> > automatically reflect the actual content (that is, include a checksum
> of
> >> > that content) for ideal client-side caching ... may simply be out of
> >> reach.
> >> >
> >> > Perhaps for modules we should use an alternate approach based on
> ETags (
> >> > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there
> would
> >> > not
> >> > need to be any version number of checksum in a module URL, but clients
> >> > would request the module content more often (and based on ETag, would
> >> often
> >> > get a 304 Not Modified). I would prefer to see a URL that changes
> when
> >> the
> >> > content changes (which prevents the request entirely).
> >> >
> >> > --
> >> > 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
> >> >
> >>
> >>
> >>
> >> --
> >> Dmitry Gusev
> >>
> >> AnjLab Team
> >> http://anjlab.com
> >>
> >
> >
> >
> > --
> > 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
> >
>
>
>
> --
> 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
>
Re: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
With the ETag support in place, there's no longer any need for the module
asset URLs to have a checksum or version number; they are no longer given a
far-future expires header.
URLs (by default) look like "/modules/t5/core/dom.js" (where the module
name is t5/core/dom).
The application version number is no longer used in any URLs; it now exists
just for documentation purposes (its written to the console at startup and
in the exception report). This is good news, because you could screw
yourself by deploying your application and NOT changing the version number
(in 5.3.6).
Very happy about this ... next up, thoughts on cometd/server-push support?
On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hl...@gmail.com>wrote:
>
>
> On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dm...@gmail.com>wrote:
>
>> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hlship@gmail.com
>> >wrote:
>>
>> > I've been working, a few hours a week, on getting per-asset checksums
>> into
>> > URLs.
>> >
>> > Some parts of this have been a challenge to accomplish without
>> completely
>> > breaking the Asset interface and a bunch of public services.
>> >
>> > For ordinary assets, it's pretty easy ... but for aggregated JavaScript
>> > libraries its been a pain that's affected a bunch of stuff.
>> >
>> > CSS files are now rewritten, since relative URLs will be broken by the
>> > addition of the checksum. I have a first (but not final) pass at this,
>>
>> where url() patterns in the CSS are converted into complete paths. This
>> > also opens the door to CSS aggregation as well as JavaScript
>> aggregation.
>> >
>> >
>> It depends on where you put the checksum.
>> If you put it as a GET parameter - then no relative URLs will be broken.
>>
>> Have you read my blog post about Tapestry5 checksums in assets?
>>
>> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
>
>
> I'll read this shortly. I've generally assumed that URLs with query
> parameters are less likely to be cached in the browser, or served properly
> by intermediate (reverse proxy) servers, but I haven't done the research.
>
>
>>
>>
>> > I still don't have a great solution for JavaScript modules;
>> RequireJS/AMD
>> > expect that there's a common root folder name (such as
>> "/assets/modules/"),
>> > and module "a/b" is simply "*root*/a/b.js". For individual modules, you
>> can
>> > write your own overrides. In fact, Tapestry has to strip off the ".js'
>> > part (which is hard-wired by RequireJS) because the actual server-side
>> > resource could be CoffeeScript or some other language that compiles to
>> > JavaScript.
>> >
>> > Short of iterating all server-side module files and writing a RequireJS
>> > config for each one (mapping each name to a URL with an embedded
>> checksum),
>> > there isn't a great solution. Alternately, something could iterate all
>> the
>> > server-side modules and built a composite checksum, but there are at
>> least
>> > a couple of virtual modules generated at runtime (and locale specific
>> for
>> > extra kicks).
>> >
>> > Modules may have to stay on the 5.3 approach: using the application
>> version
>> > number for everything.
>> >
>> > Finding the sweet spot where assets of all kinds (CSS, JavaScript
>> > libraries, JavaScript modules, etc.) can be changed freely and the URLs
>> > automatically reflect the actual content (that is, include a checksum of
>> > that content) for ideal client-side caching ... may simply be out of
>> reach.
>> >
>> > Perhaps for modules we should use an alternate approach based on ETags (
>> > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would
>> > not
>> > need to be any version number of checksum in a module URL, but clients
>> > would request the module content more often (and based on ETag, would
>> often
>> > get a 304 Not Modified). I would prefer to see a URL that changes when
>> the
>> > content changes (which prevents the request entirely).
>> >
>> > --
>> > 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
>> >
>>
>>
>>
>> --
>> Dmitry Gusev
>>
>> AnjLab Team
>> http://anjlab.com
>>
>
>
>
> --
> 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
>
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hlship@gmail.com
> >wrote:
>
> > I've been working, a few hours a week, on getting per-asset checksums
> into
> > URLs.
> >
> > Some parts of this have been a challenge to accomplish without completely
> > breaking the Asset interface and a bunch of public services.
> >
> > For ordinary assets, it's pretty easy ... but for aggregated JavaScript
> > libraries its been a pain that's affected a bunch of stuff.
> >
> > CSS files are now rewritten, since relative URLs will be broken by the
> > addition of the checksum. I have a first (but not final) pass at this,
>
> where url() patterns in the CSS are converted into complete paths. This
> > also opens the door to CSS aggregation as well as JavaScript aggregation.
> >
> >
> It depends on where you put the checksum.
> If you put it as a GET parameter - then no relative URLs will be broken.
>
> Have you read my blog post about Tapestry5 checksums in assets?
>
> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
I'll read this shortly. I've generally assumed that URLs with query
parameters are less likely to be cached in the browser, or served properly
by intermediate (reverse proxy) servers, but I haven't done the research.
>
>
> > I still don't have a great solution for JavaScript modules; RequireJS/AMD
> > expect that there's a common root folder name (such as
> "/assets/modules/"),
> > and module "a/b" is simply "*root*/a/b.js". For individual modules, you
> can
> > write your own overrides. In fact, Tapestry has to strip off the ".js'
> > part (which is hard-wired by RequireJS) because the actual server-side
> > resource could be CoffeeScript or some other language that compiles to
> > JavaScript.
> >
> > Short of iterating all server-side module files and writing a RequireJS
> > config for each one (mapping each name to a URL with an embedded
> checksum),
> > there isn't a great solution. Alternately, something could iterate all
> the
> > server-side modules and built a composite checksum, but there are at
> least
> > a couple of virtual modules generated at runtime (and locale specific for
> > extra kicks).
> >
> > Modules may have to stay on the 5.3 approach: using the application
> version
> > number for everything.
> >
> > Finding the sweet spot where assets of all kinds (CSS, JavaScript
> > libraries, JavaScript modules, etc.) can be changed freely and the URLs
> > automatically reflect the actual content (that is, include a checksum of
> > that content) for ideal client-side caching ... may simply be out of
> reach.
> >
> > Perhaps for modules we should use an alternate approach based on ETags (
> > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would
> > not
> > need to be any version number of checksum in a module URL, but clients
> > would request the module content more often (and based on ETag, would
> often
> > get a 304 Not Modified). I would prefer to see a URL that changes when
> the
> > content changes (which prevents the request entirely).
> >
> > --
> > 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
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Dmitry Gusev <dm...@gmail.com>.
On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hl...@gmail.com>wrote:
> I've been working, a few hours a week, on getting per-asset checksums into
> URLs.
>
> Some parts of this have been a challenge to accomplish without completely
> breaking the Asset interface and a bunch of public services.
>
> For ordinary assets, it's pretty easy ... but for aggregated JavaScript
> libraries its been a pain that's affected a bunch of stuff.
>
> CSS files are now rewritten, since relative URLs will be broken by the
> addition of the checksum. I have a first (but not final) pass at this,
where url() patterns in the CSS are converted into complete paths. This
> also opens the door to CSS aggregation as well as JavaScript aggregation.
>
>
It depends on where you put the checksum.
If you put it as a GET parameter - then no relative URLs will be broken.
Have you read my blog post about Tapestry5 checksums in assets?
http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html
> I still don't have a great solution for JavaScript modules; RequireJS/AMD
> expect that there's a common root folder name (such as "/assets/modules/"),
> and module "a/b" is simply "*root*/a/b.js". For individual modules, you can
> write your own overrides. In fact, Tapestry has to strip off the ".js'
> part (which is hard-wired by RequireJS) because the actual server-side
> resource could be CoffeeScript or some other language that compiles to
> JavaScript.
>
> Short of iterating all server-side module files and writing a RequireJS
> config for each one (mapping each name to a URL with an embedded checksum),
> there isn't a great solution. Alternately, something could iterate all the
> server-side modules and built a composite checksum, but there are at least
> a couple of virtual modules generated at runtime (and locale specific for
> extra kicks).
>
> Modules may have to stay on the 5.3 approach: using the application version
> number for everything.
>
> Finding the sweet spot where assets of all kinds (CSS, JavaScript
> libraries, JavaScript modules, etc.) can be changed freely and the URLs
> automatically reflect the actual content (that is, include a checksum of
> that content) for ideal client-side caching ... may simply be out of reach.
>
> Perhaps for modules we should use an alternate approach based on ETags (
> http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would
> not
> need to be any version number of checksum in a module URL, but clients
> would request the module content more often (and based on ETag, would often
> get a 304 Not Modified). I would prefer to see a URL that changes when the
> content changes (which prevents the request entirely).
>
> --
> 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
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Coming soon: per-Asset checkums in URLs
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
I agree with that. Makes it very, very fast
On Mar 12, 2013, at 6:31 AM, Bob Harner wrote:
> As a Tapestry user, I agree with your preference to prevent asset
> requests entirely rather than go the chattier ETag route. I would
> rather give up on the checksums-in-URLs idea (at least for modules)
> than have any significant increase in the number of requests to the
> server.
>
> I think Tapestry's far-future expires headers is one of its best features.
>
> On Mon, Mar 11, 2013 at 4:35 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> I've been working, a few hours a week, on getting per-asset checksums into
>> URLs.
>>
>> Some parts of this have been a challenge to accomplish without completely
>> breaking the Asset interface and a bunch of public services.
>>
>> For ordinary assets, it's pretty easy ... but for aggregated JavaScript
>> libraries its been a pain that's affected a bunch of stuff.
>>
>> CSS files are now rewritten, since relative URLs will be broken by the
>> addition of the checksum. I have a first (but not final) pass at this,
>> where url() patterns in the CSS are converted into complete paths. This
>> also opens the door to CSS aggregation as well as JavaScript aggregation.
>>
>> I still don't have a great solution for JavaScript modules; RequireJS/AMD
>> expect that there's a common root folder name (such as "/assets/modules/"),
>> and module "a/b" is simply "*root*/a/b.js". For individual modules, you can
>> write your own overrides. In fact, Tapestry has to strip off the ".js'
>> part (which is hard-wired by RequireJS) because the actual server-side
>> resource could be CoffeeScript or some other language that compiles to
>> JavaScript.
>>
>> Short of iterating all server-side module files and writing a RequireJS
>> config for each one (mapping each name to a URL with an embedded checksum),
>> there isn't a great solution. Alternately, something could iterate all the
>> server-side modules and built a composite checksum, but there are at least
>> a couple of virtual modules generated at runtime (and locale specific for
>> extra kicks).
>>
>> Modules may have to stay on the 5.3 approach: using the application version
>> number for everything.
>>
>> Finding the sweet spot where assets of all kinds (CSS, JavaScript
>> libraries, JavaScript modules, etc.) can be changed freely and the URLs
>> automatically reflect the actual content (that is, include a checksum of
>> that content) for ideal client-side caching ... may simply be out of reach.
>>
>> Perhaps for modules we should use an alternate approach based on ETags (
>> http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would not
>> need to be any version number of checksum in a module URL, but clients
>> would request the module content more often (and based on ETag, would often
>> get a 304 Not Modified). I would prefer to see a URL that changes when the
>> content changes (which prevents the request entirely).
>>
>> --
>> 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
Re: Coming soon: per-Asset checkums in URLs
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Tue, Mar 12, 2013 at 3:55 AM, Martin Grigorov <mg...@apache.org>wrote:
> Hi,
>
> On Tue, Mar 12, 2013 at 11:31 AM, Bob Harner <bo...@gmail.com> wrote:
>
> > As a Tapestry user, I agree with your preference to prevent asset
> > requests entirely rather than go the chattier ETag route. I would
> > rather give up on the checksums-in-URLs idea (at least for modules)
> > than have any significant increase in the number of requests to the
> > server.
> >
> > I think Tapestry's far-future expires headers is one of its best
> features.
>
Basically, in the future, all of Tapestry's asset handling will become more
prominent.
> >
>
> Exactly this combination will make the problems.
> If some-bundle.css contains updates in the new version of the application
> and the browser believes that it should not make a new request because of
> the far-future header and the stable url then the user will not receive the
> updates at all.
>
There's two scenarios here.
#1 some-bundle.css changes between deployments
In that case, the content hash for some-bundle.css will change, and thus
the URL will change (as the content hash is part of the URL).
#2 An image (or other asset) referenced from some-bundle.css changes
This will be caught when url() constructs inside some-bundles.css are
expanded. The target asset is located and its complete URL (including
content hash) is substituted inside the url() construct.
The content hash of some-bundle.css is computed on the version where URLs
have been expanded (not the version on the disk); some-bundle.css will also
be changed.
The client will be directed to the new version of some-bundle.css, and from
there to the new referenced asset.
> By encoding the checksum in the url the browser will have to make the
> request because for it this is a completely new resource without entry in
> its caches.
>
>
> >
> > On Mon, Mar 11, 2013 at 4:35 PM, Howard Lewis Ship <hl...@gmail.com>
> > wrote:
> > > I've been working, a few hours a week, on getting per-asset checksums
> > into
> > > URLs.
> > >
> > > Some parts of this have been a challenge to accomplish without
> completely
> > > breaking the Asset interface and a bunch of public services.
> > >
> > > For ordinary assets, it's pretty easy ... but for aggregated JavaScript
> > > libraries its been a pain that's affected a bunch of stuff.
> > >
> > > CSS files are now rewritten, since relative URLs will be broken by the
> > > addition of the checksum. I have a first (but not final) pass at this,
> > > where url() patterns in the CSS are converted into complete paths. This
> > > also opens the door to CSS aggregation as well as JavaScript
> aggregation.
> > >
> > > I still don't have a great solution for JavaScript modules;
> RequireJS/AMD
> > > expect that there's a common root folder name (such as
> > "/assets/modules/"),
> > > and module "a/b" is simply "*root*/a/b.js". For individual modules, you
> > can
> > > write your own overrides. In fact, Tapestry has to strip off the ".js'
> > > part (which is hard-wired by RequireJS) because the actual server-side
> > > resource could be CoffeeScript or some other language that compiles to
> > > JavaScript.
> > >
> > > Short of iterating all server-side module files and writing a RequireJS
> > > config for each one (mapping each name to a URL with an embedded
> > checksum),
> > > there isn't a great solution. Alternately, something could iterate all
> > the
> > > server-side modules and built a composite checksum, but there are at
> > least
> > > a couple of virtual modules generated at runtime (and locale specific
> for
> > > extra kicks).
> > >
> > > Modules may have to stay on the 5.3 approach: using the application
> > version
> > > number for everything.
> > >
> > > Finding the sweet spot where assets of all kinds (CSS, JavaScript
> > > libraries, JavaScript modules, etc.) can be changed freely and the URLs
> > > automatically reflect the actual content (that is, include a checksum
> of
> > > that content) for ideal client-side caching ... may simply be out of
> > reach.
> > >
> > > Perhaps for modules we should use an alternate approach based on ETags
> (
> > > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there
> would
> > not
> > > need to be any version number of checksum in a module URL, but clients
> > > would request the module content more often (and based on ETag, would
> > often
> > > get a 304 Not Modified). I would prefer to see a URL that changes when
> > the
> > > content changes (which prevents the request entirely).
> > >
> > > --
> > > 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
> >
> >
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
>
--
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
Re: Coming soon: per-Asset checkums in URLs
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Tue, Mar 12, 2013 at 11:31 AM, Bob Harner <bo...@gmail.com> wrote:
> As a Tapestry user, I agree with your preference to prevent asset
> requests entirely rather than go the chattier ETag route. I would
> rather give up on the checksums-in-URLs idea (at least for modules)
> than have any significant increase in the number of requests to the
> server.
>
> I think Tapestry's far-future expires headers is one of its best features.
>
Exactly this combination will make the problems.
If some-bundle.css contains updates in the new version of the application
and the browser believes that it should not make a new request because of
the far-future header and the stable url then the user will not receive the
updates at all.
By encoding the checksum in the url the browser will have to make the
request because for it this is a completely new resource without entry in
its caches.
>
> On Mon, Mar 11, 2013 at 4:35 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
> > I've been working, a few hours a week, on getting per-asset checksums
> into
> > URLs.
> >
> > Some parts of this have been a challenge to accomplish without completely
> > breaking the Asset interface and a bunch of public services.
> >
> > For ordinary assets, it's pretty easy ... but for aggregated JavaScript
> > libraries its been a pain that's affected a bunch of stuff.
> >
> > CSS files are now rewritten, since relative URLs will be broken by the
> > addition of the checksum. I have a first (but not final) pass at this,
> > where url() patterns in the CSS are converted into complete paths. This
> > also opens the door to CSS aggregation as well as JavaScript aggregation.
> >
> > I still don't have a great solution for JavaScript modules; RequireJS/AMD
> > expect that there's a common root folder name (such as
> "/assets/modules/"),
> > and module "a/b" is simply "*root*/a/b.js". For individual modules, you
> can
> > write your own overrides. In fact, Tapestry has to strip off the ".js'
> > part (which is hard-wired by RequireJS) because the actual server-side
> > resource could be CoffeeScript or some other language that compiles to
> > JavaScript.
> >
> > Short of iterating all server-side module files and writing a RequireJS
> > config for each one (mapping each name to a URL with an embedded
> checksum),
> > there isn't a great solution. Alternately, something could iterate all
> the
> > server-side modules and built a composite checksum, but there are at
> least
> > a couple of virtual modules generated at runtime (and locale specific for
> > extra kicks).
> >
> > Modules may have to stay on the 5.3 approach: using the application
> version
> > number for everything.
> >
> > Finding the sweet spot where assets of all kinds (CSS, JavaScript
> > libraries, JavaScript modules, etc.) can be changed freely and the URLs
> > automatically reflect the actual content (that is, include a checksum of
> > that content) for ideal client-side caching ... may simply be out of
> reach.
> >
> > Perhaps for modules we should use an alternate approach based on ETags (
> > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would
> not
> > need to be any version number of checksum in a module URL, but clients
> > would request the module content more often (and based on ETag, would
> often
> > get a 304 Not Modified). I would prefer to see a URL that changes when
> the
> > content changes (which prevents the request entirely).
> >
> > --
> > 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
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: Coming soon: per-Asset checkums in URLs
Posted by Bob Harner <bo...@gmail.com>.
As a Tapestry user, I agree with your preference to prevent asset
requests entirely rather than go the chattier ETag route. I would
rather give up on the checksums-in-URLs idea (at least for modules)
than have any significant increase in the number of requests to the
server.
I think Tapestry's far-future expires headers is one of its best features.
On Mon, Mar 11, 2013 at 4:35 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been working, a few hours a week, on getting per-asset checksums into
> URLs.
>
> Some parts of this have been a challenge to accomplish without completely
> breaking the Asset interface and a bunch of public services.
>
> For ordinary assets, it's pretty easy ... but for aggregated JavaScript
> libraries its been a pain that's affected a bunch of stuff.
>
> CSS files are now rewritten, since relative URLs will be broken by the
> addition of the checksum. I have a first (but not final) pass at this,
> where url() patterns in the CSS are converted into complete paths. This
> also opens the door to CSS aggregation as well as JavaScript aggregation.
>
> I still don't have a great solution for JavaScript modules; RequireJS/AMD
> expect that there's a common root folder name (such as "/assets/modules/"),
> and module "a/b" is simply "*root*/a/b.js". For individual modules, you can
> write your own overrides. In fact, Tapestry has to strip off the ".js'
> part (which is hard-wired by RequireJS) because the actual server-side
> resource could be CoffeeScript or some other language that compiles to
> JavaScript.
>
> Short of iterating all server-side module files and writing a RequireJS
> config for each one (mapping each name to a URL with an embedded checksum),
> there isn't a great solution. Alternately, something could iterate all the
> server-side modules and built a composite checksum, but there are at least
> a couple of virtual modules generated at runtime (and locale specific for
> extra kicks).
>
> Modules may have to stay on the 5.3 approach: using the application version
> number for everything.
>
> Finding the sweet spot where assets of all kinds (CSS, JavaScript
> libraries, JavaScript modules, etc.) can be changed freely and the URLs
> automatically reflect the actual content (that is, include a checksum of
> that content) for ideal client-side caching ... may simply be out of reach.
>
> Perhaps for modules we should use an alternate approach based on ETags (
> http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would not
> need to be any version number of checksum in a module URL, but clients
> would request the module content more often (and based on ETag, would often
> get a 304 Not Modified). I would prefer to see a URL that changes when the
> content changes (which prevents the request entirely).
>
> --
> 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