I also recommend concurrently engaging Fabrice to think about contingency plans, especially as you're looking to deploy this immanently. If you absolutely had to cut some functionality out in order to roll this out more broadly, what would you eliminate? It's always good to have a plan like that in your pocket, even if you don't end up resorting to it.

If it gets close to crunch time and you need me to clear my schedule and focus on this, let me know -- you have that lifeline too.

I hope this is helpful. I think you're doing great work and I'm looking forward to seeing this feature graduate out of beta.

On Fri, Apr 25, 2014 at 6:27 PM, Ori Livneh ori@wikimedia.org wrote:

On Thu, Apr 17, 2014 at 1:13 AM, Gilles Dubuc gilles@wikimedia.orgwrote:

...

Are these requests done on each page view, or only once a user explicitly

...

opens the media viewer?

When the user opens media viewer, but there are 4 API calls per image and we preload the next/previous images fairly quickly after opening one. So generally within a few seconds, you're looking at 12 API calls when opening Media Viewer.

That's way too high. Since you're planning to deploy this soon, we should figure out how to meet the requirements using the infrastructure that we have rather than the one we'd like to have. Have you considered adding a MediaWiki API module to your extension that composes the data into a single response? You could do this without duplicating code by constructing DerivativeRequest objects to each endpoint, as described in < https://www.mediawiki.org/wiki/API:Calling_internally%3E.

If you wanted to get really creative, you could experiment with ways of composing the image itself into the response. One case where we are already multiplexing code and binary data is to be found in ResourceLoader, which embeds small images as data URIs in CSS. Another way to multiplex image and metadata is to have Swift annotate files with extra EXIF tags and parse those on the client. But these ideas would require a lot of exploratory work to determine their viability, so for now the most practical course is the one I described in the first paragraph of my response.