I've committed a change to MediaWiki's media file handling: modularisation
of file-type specific operations such as rescaling of images and
in-browser display. These modules are referred to as media handlers. As I
hinted in my post on the image/media/download pseudo-namespaces, this
change is intended to make it easier to implement support for audio and
video files in MediaWiki. With a few minor changes to the wikitext parsing
code and an extra media handler module, we should be able to support audio
and video in the core on the same footing as images.
This change also makes it much simpler to add extra image formats. Instead
of having special cases and if/elseif/else structures dotted throughout
the code, the relevant functions are delegated to a media handler
identified by MIME type.
Most of the old API has been retained for backwards compatibility. The
most significant function to be introduced is Image::transform(), which
transforms a media file with a handler-specific set of parameters. It
returns a MediaTransformOutput object, which contains methods for
in-browser display, as well as the data needed for remote or asynchronous
transformation.
Media handlers are a subproject of a larger project which has been
assigned to me, to change the architecture of the image backend. Basically
the idea is to get rid of NFS for local network image data transfer, and
to replace it with a private HTTP-based API. Early work for this API is in
the WebStore extension in svn.
In the MediaWiki core, this means abstracting local file operations. On
the server administration side, we intend to have a cluster of image
storage backends, possibly replicated and load balanced, instead of the
current single backend server. We're staying with file-based storage for
now. We intend on leaving the proposed filesytem layout changes until
after these backend architectural changes have been made.
These backend changes are definitely our first priority. But once the
backend changes are out of the way, here are some features I'd like to
think about:
* Embedded video and audio support, with asynchronous recoding into
different formats (say by polling the recode status with JavaScript)
* Support for large file uploads directly to the image backend servers,
probably using some kind of browser-embedded applet.
* Support for an arbitrary number of image repositories accessible from
each wiki, instead of the two currently offered by MediaWiki (commons and
local). Remote repositories like that in the InstantCommons proposal would
be one application. Fetching images from arbitrary wikis using an
interwiki-like syntax would also be a possibility.
-- Tim Starling