On Tue, Jul 28, 2015 at 3:57 PM, Brian Gerstle <bgerstle(a)wikimedia.org>
wrote:
I guess the "thumb/6/6e" part isn't standard either.
It's always there as far as I know, but it's not standard in the sense that
there is no promise of stability. Someone might at some point decide we
should use a faster hash function or we have too many images and need three
levels of depth or something else altogether... File names might go away
soon as well as there are some experiments with using content hash based
URLs so that cache invalidation becomes simpler.
So if you want to freeze elements of the current URL structure that should
be a wider discussion involving ops and other folks working on media
features. You can of course just use it at your own risk, for a JS
component that would be no big deal as URL schemas don't change often; not
sure how quickly app updates can be pushed out though.
If we could just get the thumbnail server to return
the original image
when we go too large we'd be set.
Fragmenting the cache would be problematic (if it comes to that, it's still
better to fragment the HTML cache by appending an image size parameter
since HTML content is smaller). I think something like T75935
<https://phabricator.wikimedia.org/T75935> could work but AIUI the whole
media cache infrastructure is held together with duct tape and no one is
particularly enthusiastic to poke at it.
We could always request it anyway and fall back manually in case of 400
response (probably won't happen _too_ often).
MediaViewer does that (it also embeds the original size in the article HTML
and uses that to guess the right URL); it mostly works but still comes with
minor issues such as T70320 <https://phabricator.wikimedia.org/T70320> or
strange errors on the beta cluster which has minor differences in thumbnail
behavior.