Gregory Szorc wrote:
In case anyone hasn't noticed, the number of MediaWiki extensions in existence has soared in the previous year. They are scattered all around the internet and it is a chore to make sure all of your extensions are up to date.
In an attempt to alleviate the confusion of managing extensions, I propose a more formal extension system.
Step 1: Overhaul how MediaWiki deals with extensions. Loading an extension via 'require_once' is silly and has all sorts of limitations (for example, if your extension file which modifies $wgExtensionFunctions is loaded from within a function, $wgExtensionFunctions won't actually get modified unless it is brought into scope of the calling function). In addition, there is no easy way to tell if an extension is a special page extension, parser hook extension, combination, etc. In my proposed system, MediaWiki extensions would all be derived from a base 'Extension" class. There would be interfaces that would allow extensions to become a SpecialPage extension, parser extension, hook extension, etc. Furthermore, if extensions were packaged as a class, we could give the base extension class useful variables, such as "sourceURL" which would allow developers to provide a URL to the most up-to-date version of an extension. Of course, the ultimate benefit to turning extensions into classes is that it would make developing extensions easier since OOP gives you a building block for your work, not a clean slate.
Step 2: Write a manager for MediaWiki that allows you to load and upgrade extensions remotely. Want to upgrade an extension? Just go to a special page, hit the button to refresh the list for updates, and click the checkbox next to the extension you want to update.
Critics out there will retort that this will slow things down. Yes, it won't be as fast as explicitly typing require_once in LocalSettings.php. However, the system could also be designed with speed in mind. For example, it would be possible to serialize all the loaded extension objects into a file (or shared memory) which is loaded for every page request. I take this approach with my new Farmer extension ( http://www.mediawiki.org/wiki/User:IndyGreg/Farmer), which allows you to specify which extensions are loaded via a web interface. The performance hit is negligible.
Thoughts?
Please read my own proposal for reworking the extension interface at:
http://mail.wikipedia.org/pipermail/wikitech-l/2006-July/037035.html
Posted to this list 10 days ago.
500us per extension at startup time is too slow, I'm aiming to make extensions much faster than they are at the moment, not slightly slower. Under your proposal, serializing extension classes doesn't help much, since the code would still have to be loaded before unserialization could take place. You describe no system for registering capabilities, besides a vague suggestion that there would be an "interface" for various things. When a request comes in for Special:Whatchmacallit, or the parser encounters a {{#foo:xyz}} tag, how does it determine what function it needs to call? If everything about the extension is embodied in functional interfaces of the extension object, then hundreds of lines of code will need to be executed on startup to provide for registration. This is unacceptable. My suggestion is to use a module specification file to provide:
a) a map between capabilities and callbacks b) a map between classes and files, for autoloading
The classes containing the hook functions could be derived from some common Extension parent class, assuming some use could be found for such a paradigm. Since the essential thing which turns a class into an extension would be the specification file, there might not be much need for functionality in a common base class.
-- Tim Starling