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(a)wikimedia.org> wrote:
On Thu, Apr 17, 2014 at 1:13 AM, Gilles Dubuc
<gilles(a)wikimedia.org>wrote;wrote:
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>gt;.
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.