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
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.
Thanks Dantman,
(1.) I agree, maybe it's better that I don't take over an existing RFC -- it sounded like a good idea at first!
(2.) A configuration database for Mediawiki would be awesome. Extension:Update is trying to do the same thing and I think the extension repository can benefit from this immensely. A GUI configuration manager would fit right in, and storing the configs in a database makes sense. Although it would be easier to work in a working implementation of the configuration manager, I think it is not a required perquisite. As long as there's a defined interface established early in each project they can be developed simultaneously.
(3.) I've edited the "Thoughts on client-server model" section to clarify things and incorporate your thoughts. This is the exact reason for comments -- I rarely think of things that are obvious to others.
(4.) Current extensions will always work -- they are hardcoded that way. Any extensions developed (or retrofitted) to work with the proposed management system will have a superset of functionality that is currently required. An ideal situation would be a script to partially convert a "require_once()" extension to a "managed" one. (Of course version info and dependency info will need to be figured out and added manually.)
-DanielRenfro
On Saturday, July 28, 2012 at 9:29 PM, Daniel Friesen wrote:
On Sat, 28 Jul 2012 17:33:42 -0700, Daniel Renfro <bluecurio@gmail.com (mailto: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 (http://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.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Jul 28, 2012 at 9:29 PM, Daniel Friesen lists@nadir-seen-fire.com wrote:
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.
Yes. Let's please please please not try to tackle this until config mgmt is in core.
"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.
This was a silly idea I had when writing this up originally. The main goal was to prevent extensions pasted into wiki pages.
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.
This.
-Chad
Well, I'm willing to work on an extension manager whenever it is ready to be started. Feel free to edit the RFC page, I'm trying to make it fairly comprehensive.
-Daniel
On Sunday, July 29, 2012 at 10:36 AM, Chad wrote:
On Sat, Jul 28, 2012 at 9:29 PM, Daniel Friesen <lists@nadir-seen-fire.com (mailto:lists@nadir-seen-fire.com)> wrote:
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.
Yes. Let's please please please not try to tackle this until config mgmt is in core.
"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 (http://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.
This was a silly idea I had when writing this up originally. The main goal was to prevent extensions pasted into wiki pages.
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.
This.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Part of this should be a base class for extensions to use, e.g. WikiMediaExtension. Should be nice to save some code needed in all extensions and perhaps we could deprecate some globals related to extensions registration. Also, this will require some updates for the extensions development manuals on mw org. This could probably even be done and discussed in parallel of the configuration database development.
2012/7/30 Daniel Renfro bluecurio@gmail.com:
Well, I'm willing to work on an extension manager whenever it is ready to be started. Feel free to edit the RFC page, I'm trying to make it fairly comprehensive.
-Daniel
On Sunday, July 29, 2012 at 10:36 AM, Chad wrote:
On Sat, Jul 28, 2012 at 9:29 PM, Daniel Friesen <lists@nadir-seen-fire.com (mailto:lists@nadir-seen-fire.com)> wrote:
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.
Yes. Let's please please please not try to tackle this until config mgmt is in core.
"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 (http://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.
This was a silly idea I had when writing this up originally. The main goal was to prevent extensions pasted into wiki pages.
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.
This.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org