On Sun, May 29, 2016 at 7:08 PM, Brion Vibber bvibber@wikimedia.org wrote:
IIRC, InstantCommons is slightly trickier as you also need to make multiple API calls to fetch thumbnail URLs, made even worse by needing to fetch multiple resolutions for srcset. This gets real nasty if there are a lot of files and the thumbnail ref data isn't cached...
We could change all that if there was a stable enough URL/linking API... Can probably fake it for common cases and supported handlers by generating a URL like we would for a local 404-handler repo; my main concern is for future expansion where we add more fancy types on Commons where the local site may not have an extension installed locally.
Not sure if trying to use an unhandled file type via InstantCommons makes sense; the image parameters in the wikitext and the image parameters in the URL (or imageinfo API or hypothetical linking API) don't necessarily use the same syntax; what would transform that? (Granted, you get similar problems when parameter transformation is handled by the local extension and there is a version mismatch between the local and remote installation.)
Fetching all thumbnail URLs in a single request is T56037 https://phabricator.wikimedia.org/T56037 and should not be particularly complicated. Fetching the thumbnails themselves, well, if you care about speed, you probably use hotlinking https://phabricator.wikimedia.org/T114098#1717456 or a 404 handler anyway.
(Iframe embedding as a fallback for unknown handlers sounds possible, could expose a frame URL in the imageinfo data.)
In general that would be a nice idea (see T27854 https://phabricator.wikimedia.org/T27854). Specifically for embedding unknown file types in MediaWiki though, we would probably have to introduce some standard key-value syntax for image parameters first, instead of the current mess where it's parsed by an arbitrary set of regexes defined by the media handlers and generated in a similarly flexible way. And then you still have the problem of handling unknown media types in VisualEditor which would need some kind of parameter metadata at least.