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(a)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(a)wikimedia.org> wrote:
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.
--
EN Wikipedia user page:
https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle