On Sat, 28 Jul 2012 17:33:42 -0700, Daniel Renfro bluecurio@gmail.com wrote:
To all developers:
I would like to gather some feedback for an idea that has been around for a while -- implementing an extension manager for Mediawiki.
The topic came up a few times recently at Wikimania 2012's "Ask the developers" session and got me thinking. I've been developing with Mediawiki for 7 years now and have no contributed anything significant to the community. I've taken on this project as a serious opportunity to contribute, and would like to get some comments, opinions, and general feedback (if not some interested parties willing to help out!) I've expanded the current "request for comments" page to include a history of the idea and a number of ideas for features.
You can view the proposal at [ http://www.mediawiki.org/wiki/Requests_for_comment/Extension_release_managem... ]. Please leave your comments on the Talk page (and don't forget to sign your name!)
-Daniel
MW: http://www.mediawiki.org/wiki/User:DanielRenfro IRC: daniel_renfro
Shouldn't you have created your own RFC instead of usurping ^demon/Chad's?
Speaking of Chad. He's been dying to work on his project trying to create a configuration database for MediaWiki. He's been busy with Gerrit stuff but hoping to work on configuration after that's done.
I think that extension management is the second step. We can't have a good system for installing extensions in a UI when we don't even have a good system for configuring MediaWiki in a UI.
I don't like what's in the "Thoughts on client-server model" section. - Firstly a lot of the reasoning is based on the assumption "The repository would most definitely be an instance of Mediawiki itself". But there's no reason provided why we need to do that. Almost no-one needs the ability to run a centralized repository besides Wikimedia and perhaps some in-house environments that want to handle extensions themselves (and a good portion of those may not want to even bother with this remote stuff; They'll just run some script to distribute extension code to their servers and run install scripts). So there is no reason that the server needs to be written in PHP much less be part of MediaWiki. There are other languages and many of them may have libraries that are better at doing this kind of thing on the server than PHP does it. I see no reason to preclude the possibility of using a different language if someone shows that there would be some advantage to doing so. - This section appears to assume that extension distribution would be handled by the server including the code for all extensions inside of it's extensions/ directory and serving them out. This does not seem right. Extension distribution code will likely involve something that interacts more directly with code repositories or allows uploading of tarballs than something that just serves files from a directory. In fact that's almost necessary to properly handle versions. - I should probably point this out as a side point. Wikimedia host the standard central repository. Even if we 'were' to develop something the way you describe there where the wiki distributes extensions it serves itself. Wikimedia would probably NOT be using this system to distribute extensions to it's own wikis. ie: There is no recursive problem anyways because Wikimedia wouldn't be using the system to distribute itself.
"Extension pages can ONLY exist (excluding subpages) if an extension has been defined in the database, a path to the repo given, and author(s) defined" I see no reason to lock in an Extension: page = part of the repository setup like this. We can provide parser functions and whatnot to display extension information on Extension: pages on MW.org. And we can use some method to use information on the extension base itself to define some information for extensions, etc... but Extension pages and extension management will be two separate things.
"(requirement) don't break the current extensions" Extensions currently depend on our old method of configuration. This means that the idea of installing an extension via interface and the idea of keeping extensions as-is is already incompatible. Extensions are inevitably going to need to be tweaked to start working in an interface based installation environment. Unless you just mean that new versions of MediaWiki should keep working with old require_once based extensions until they migrate to the extension installer setup.