Aaron did some work on hash-based thumb naming that was recently merged: https://phabricator.wikimedia.org/T1210
A switch to hash-based thumb urls could be an opportunity to define a predictable size / quality selection API, at least for large installations like ours.
Gabriel
On Tue, Jul 28, 2015 at 4:33 PM, Brian Gerstle bgerstle@wikimedia.org wrote:
the whole media cache infrastructure is held together with duct tape and
no one is particularly enthusiastic to poke at it.
That's what I found out when I asked around on IRC about this very thing. Could we get sufficient, inter-vertical commitment to do this properly if there were, say, a cross-platform epic about it next quarter? Just a thought...
On Tue, Jul 28, 2015 at 7:25 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Jul 28, 2015 at 3:57 PM, Brian Gerstle bgerstle@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.
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle