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 <[email protected]> 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 <[email protected]> wrote: > >> On Tue, Jul 28, 2015 at 3:57 PM, Brian Gerstle <[email protected]> >> 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 > -- Gabriel Wicke Principal Engineer, Wikimedia Foundation
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
