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 <bluecu...@gmail.com > (mailto:bluecu...@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_management > > > > ]. 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 > > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
