"Perfect" asset URLs

[Howard Lewis Ship <hl...@gmail.com>]

I'm part of the way through CSS aggregation and I've got the code that
handles URL rewriting inside CSS files.

At this point, I can see changing the version number incorporated into
/asset URLs to be per-asset, rather than the application version number;
the version number would be a MD5 or SHA1 hash of the (uncompressed)
content of the file.

This would be great, as it means that an upgrade of the application to a
new deployment, with a proper new application version number, would NOT
invalidate the vast majority of assets: those assets that have not changed
will maintain a consistent URL, and likely be already cached in end-user's
browsers.

Unfortunately, I have yet to come up with a reasonable way to accomplish
the same thing for AMD modules ... but I'm working on it.

-- 
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: "Perfect" asset URLs

[Bob Harner <bo...@gmail.com>]

It might make sense to use a simple CRC ckecksum here rather than a
cryptographic hash -- faster to calculate, and fewer characters to add to
the page.
On Jan 13, 2013 7:18 AM, "Bob Harner" <bo...@gmail.com> wrote:

> I like the plan a lot. I don't think the size is much concern. Thousands
> of small ints in a map don't add up to much memory if the map is shared
> application-wide and not per-session.
> On Jan 12, 2013 11:31 PM, "Kalle Korhonen" <ka...@gmail.com>
> wrote:
>
>> On Sat, Jan 12, 2013 at 5:57 PM, Howard Lewis Ship <hl...@gmail.com>
>> wrote:
>>
>> > I'm part of the way through CSS aggregation and I've got the code that
>> > handles URL rewriting inside CSS files.
>> > At this point, I can see changing the version number incorporated into
>> > /asset URLs to be per-asset, rather than the application version number;
>> > the version number would be a MD5 or SHA1 hash of the (uncompressed)
>> > content of the file.
>> >
>>
>> Presumably you'd calculate the hash on first access to the asset? Would
>> you
>> keep the hash memory for subsequent request? That's potentially a lot of
>> small items to be kept in memory. I still think that the easiest option
>> would be to use a module specific version - if module supplies one, you
>> use
>> that (and only that), otherwise the application version.
>>
>> Kalle
>>
>>
>>
>> > This would be great, as it means that an upgrade of the application to a
>> > new deployment, with a proper new application version number, would NOT
>> > invalidate the vast majority of assets: those assets that have not
>> changed
>> > will maintain a consistent URL, and likely be already cached in
>> end-user's
>> > browsers.
>> >
>> > Unfortunately, I have yet to come up with a reasonable way to accomplish
>> > the same thing for AMD modules ... but I'm working on it.
>> >
>> > --
>> > 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: "Perfect" asset URLs

[Bob Harner <bo...@gmail.com>]

I like the plan a lot. I don't think the size is much concern. Thousands of
small ints in a map don't add up to much memory if the map is shared
application-wide and not per-session.
On Jan 12, 2013 11:31 PM, "Kalle Korhonen" <ka...@gmail.com>
wrote:

> On Sat, Jan 12, 2013 at 5:57 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> > I'm part of the way through CSS aggregation and I've got the code that
> > handles URL rewriting inside CSS files.
> > At this point, I can see changing the version number incorporated into
> > /asset URLs to be per-asset, rather than the application version number;
> > the version number would be a MD5 or SHA1 hash of the (uncompressed)
> > content of the file.
> >
>
> Presumably you'd calculate the hash on first access to the asset? Would you
> keep the hash memory for subsequent request? That's potentially a lot of
> small items to be kept in memory. I still think that the easiest option
> would be to use a module specific version - if module supplies one, you use
> that (and only that), otherwise the application version.
>
> Kalle
>
>
>
> > This would be great, as it means that an upgrade of the application to a
> > new deployment, with a proper new application version number, would NOT
> > invalidate the vast majority of assets: those assets that have not
> changed
> > will maintain a consistent URL, and likely be already cached in
> end-user's
> > browsers.
> >
> > Unfortunately, I have yet to come up with a reasonable way to accomplish
> > the same thing for AMD modules ... but I'm working on it.
> >
> > --
> > 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: "Perfect" asset URLs

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

On Sat, Jan 12, 2013 at 5:57 PM, Howard Lewis Ship <hl...@gmail.com> wrote:

> I'm part of the way through CSS aggregation and I've got the code that
> handles URL rewriting inside CSS files.
> At this point, I can see changing the version number incorporated into
> /asset URLs to be per-asset, rather than the application version number;
> the version number would be a MD5 or SHA1 hash of the (uncompressed)
> content of the file.
>

Presumably you'd calculate the hash on first access to the asset? Would you
keep the hash memory for subsequent request? That's potentially a lot of
small items to be kept in memory. I still think that the easiest option
would be to use a module specific version - if module supplies one, you use
that (and only that), otherwise the application version.

Kalle



> This would be great, as it means that an upgrade of the application to a
> new deployment, with a proper new application version number, would NOT
> invalidate the vast majority of assets: those assets that have not changed
> will maintain a consistent URL, and likely be already cached in end-user's
> browsers.
>
> Unfortunately, I have yet to come up with a reasonable way to accomplish
> the same thing for AMD modules ... but I'm working on it.
>
> --
> 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
>