I use a similar technique for my facebook app, except based off the
timestamp of the resource. Facebook does heavy caching of resources
it pulls from your server. Not suggesting we use timestamps, just
validating the general concept.
To speed things up you could probably think up a way to not have to
always generated an md5 upon request of a resource as I'm not sure how
fast doing md5s on demand would be (I think perhaps a function of the
resource size?).
Craig.
--
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
twitter: craiger
On 16-Apr-09, at 5:31 PM, Jeremy Thomerson wrote:
I saw that Igor posted a link to the blog post below [1] in
reference to
another thread. That made me think - and I haven't looked, maybe
we're
already doing something like this. But, what if we calculated the
MD5 for
resources and appended that to the URL that we generate? That way,
we can
automatically set a long expires header, but since the URL would
change if
the resource changes, then we automatically handle this. It seems
like
something that would be broadly beneficial.
Thoughts?
[1] -
http://techblog.molindo.at/2008/08/wicket-interface-speed-up-caching-resources-forever.html
--
Jeremy Thomerson
http://www.wickettraining.com
