On 4/21/07, Tim Starling tstarling@wikimedia.org wrote:
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
I think that all posts similar to this post should be gathered on some wiki page, histroy of mediawiki or evolving mediawiki .. something to tell people how it became to that way in how many steps...just a thought