Just thought I'd float this idea for comments before I try working on it...
Between multi-megapixel digital photographs and other wacky multimedia
fun, uploads are taking up an ever-huger amount of disk space,
bandwidth, etc. Our existing primary image fileserver is a bit sluggish;
a new one with a nice big drive array is on order but we still would
like to provide for better local and downstream caching.
It would make caching much easier if the file at a given URL was
immutable; that is, if a replacement image has a different URL from the
old one.
For an example of the problem with mutable images, take this scenario:
1) A featured article has a photo, say, [[Image:Puppy.jpg]]
2) Somebody uploads goatse.cx on top of it.
3) A visitor comes, and fetches the goatse image at:
http://upload.wikimedia.org/wikipedia/en/a/a1/Puppy.jpg
His ISP's transparent proxy caches the image.
4) An admin reverts the image back to the puppy and protects it.
5) Another visitor loads the article, and fetches the puppy image at
http://upload.wikimedia.org/wikipedia/en/a/a1/Puppy.jpg
He's from the same ISP, and the proxy returns the previously loaded
goatse image.
6) The visitor e-mails the Wikimedia board to complain about their *very
offensive* web site. ;)
One possibility is to embed the timestamp into the URL. So the goatse
version might be:
http://upload.wikimedia.org/wikipedia/en/2005/10/23/074223/Puppy.jpg
and the reverted image would get a different URL, a few minutes later:
http://upload.wikimedia.org/wikipedia/en/2005/10/23/074506/Puppy.jpg
(The article pages need to be rerendered with the new link, but this is
already necessary to accomodate changes in size, etc. Articles are
forced to be rechecked from end-clients and are only cached by proxies
we control and send explicit purges to, so that 'should' stay under
control.)
This scheme would allow for outside proxy caches to cache a given image
file indefinitely without it becoming dangerously stale, as well as more
permanent on-demand replicated image servers to distribute bandwidth
across our clusters without stealing squid cache space from articles.
A downside is that image URLs aren't predictable ahead of time; unless
you're in the database to check what the latest version of the image is
you can't build the URL from just a file name. One could though concoct
a litte special page or something to redirect to whatever the current
version is.
Another benefit is that not having the "/a/ad/" cache directory will
allow people with badly written ad blockers to see the missing 1/256th
of our images again. ;)
-- brion vibber (brion @
pobox.com)
