Various people wrote: [I've picked this response just because it's the most recent, various people have been making similar points.]
So you might have something like: http://upload.wikimedia.org/584/590/5845907fdfc6eb1125129c4ce0da0704c49 6a7e4.jpg
Obviously a disadvantage is that the filenames are ugly. One might tack a 'pretty' but ignored filename on the end, using rewrites or whatever tool to drop it on the backend:
http://upload.wikimedia.org/584/590/5845907fdfc6eb1125129c4ce0da0704c49 6a7e4/Puppy.jpg
Which is still very human-unfriendly. I couldn't remember this URl even if my life depended on it!
The question that occurs to me is, quite simply, why do humans ever *need* to know or manipulate such URIs?
* anyone wanting to "bookmark" a particular image will want to link to its description page (to show copyright info, possible replacements, etc); if that's not the case, we need to redesign our image description pages (this may be the case w.r.t. Commons).
* anyone *saving* the image ("downloading" it, as they would describe it) would only see the *filename* part (as the default name); as long as we tack on the "friendly name" at the end (even just to ignore) the rest of the URI can be anything at all
* anyone wanting to include an image *inline* in an external site is abusing our bandwidth (either maliciously or just through naivety)
* somebody mentionned bot authors; but what purpose do bot authors have with the absolute URI of an image? Creating a static dump by screen-scraping rather than parsing the wikitext dump?
* a user-side renderer (e.g. WikiWyg, Pilaf's Live Preview) might need to know them to render fully, I suppose; like distinguishing "red" and "blue" internal links, this could ideally be done through some minimal "API", question and answer style
In short, I don't see any need for making these URIs "pretty", or even providing a Special page that redirects, except as a [bad] substitute for a "bot API" that allows you to request the current full URI. I *do*, however, see some very good reasons for tacking a pretty *filename* on as the last part, even if it's actually ignored (e.g. for "save as", as mentionned above).
Actually, we might want to do more than just ignore the pretty name, because (esp. knowing IE) it rmight be dangerous if http://..../abc123/Puppy.jpeg and http://..../abc123/Puppy.txt are valid URIs for the same file. To keep things static, we don't really want to check this explicitly, but perhaps the "pretty bits" could actually exist on the filesystem, as symlinks or such: http://.../abc123/abc123 [actual content] http://..../abc123/Puppy.jpeg [symlink to above] http://..../abc123/JSC0123.jpg [symlink to above; old or alternative name] http://..../abc123/Haxx0r.txt [no symlink here, so returns HTTP 404]
-- Rowan Collins BSc [IMSoP]