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.
I thought I had suggested this a long time ago already. :)
In my opinion, you should redesign the image/oldimage table structure in
the same way that cur/old was changed into page/revision. Each image
revision, whether "current" or not, should have a numerical ID for a
primary key. You can then use that integer in your unique URLs. (I am
against the idea of timestamps because they are never unique. ;-) ) This
has the added bonus side-effect that (a) when an image gets overwritten
by a new version, the old image's URL is still the same; (b) reverting
to an older image revision allows you to just revert to the old URL
instead of creating a new one, thereby somewhat helping caching. You
could even use MD5/SHA1/whatever checksums to detect duplicate uploads
and re-use the already-existing image revision with its already-existing
URL.
LiveJournal did the same originally with their user picture URLs. I
realise they ran into the concern that it would allow people to
enumerate all user pictures, giving an easy way to write a good-faith
script that would kill the servers. As a counter-measure, they added the
numerical ID of the user the image belongs to to the URL as well. Since
that never changes either, you still have the nice 'permanent URLs' effect.
So we will have to think about whether we have the same concern. If we
do, we can add the numerical user ID of the image's uploader to its URL,
or (as we do already) part of a checksum. We currently checksum the
image's filename, however, which I strongly object to, because it makes
it harder to code an image-renaming feature. If we're going to redesign
this anyway, we might as well make it so that this feature will be
easier to code in the future.
Note also that the most commonly requested image-related feature is the
ability to undelete an image, thereby removing the last bit of
irreversibility in an admin's toolset.
Timwi