> > 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
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
