- One of the earliest problems I encountered was providing a system for updating configuration, it would be very difficult to maintain variables in a file so moving to configuration in the database is probably the only choice here (possibly both a database based and file based choices, but this could become hard to maintain).

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Recently I volunteered to help establish a system for providing an extension manager\repository combination for MediaWiki. During this time I have devoted some thought regarding how such a system would work, here I hope to summarize what ideas have been bounced around so far and stimulate further discussion that can be built upon. To begin with, most of my effort went into designing and building a repository, doing this first was a bad idea, however; a manager that can be used without a repository is needed first before the specification for a repository can be made. Regardless thought has already been put into this (mostly in IRC discussions on #mediawiki) so it would be worthwhile listing ideas them here. - It is *extremely* dangerous to create a system that automatically downloads files that will be executed from the Internet and installed into an environment such as MediaWiki, if the repository that is being used is compromised via DNS spoofing or similar attacks, arbitrary access to the file system the client MediaWiki is running on and any data held in the wiki could be made available (without anyone knowing, if the malicious attack was crafted carefully). - For this reason signing should be used to facilitate transferring files between the repository and MediaWiki in a way similar to aptitude (Linux package manager). Perhaps done using SSL or some other system (maybe using public\private keys). - It should be possible for multiple repositories to be hosted, even if an official one were to exist some projects might like to have one so that their wikis can access custom extension and many other reasons. Once I develop my repository system I plan to release it under an open source license in a generalized way so it could be used by third parties as well as on a pseudo-official one probably hosted on the toolserver (maybe even the stable server after a while). - Due to the high demand such a system would receive static generated information would be desirable as opposed to a dynamic API. - Support for different versions of MediaWiki would be essential, presumably from the version of MediaWiki available when the extension manager is released onwards (therefore future backwards compatibility would be essential). That's all I could think of for the repository, please add more in a reply if you can think of anything. Moving on to the client (extension manager) many more factors would have to be covered. - One of the earliest problems I encountered was providing a system for updating configuration, it would be very difficult to maintain variables in a file so moving to configuration in the database is probably the only choice here (possibly both a database based and file based choices, but this could become hard to maintain). Validation on input would be required and so more coding would need to be made by extension authors (or the repository managers, if the maintainer of the extension wasn't willing to put effort into validation functions), this could probably be done using a configuration class for each extension extend from a main configuration class. This would most likely fit best into a separate configuration file so it could be loaded without the rest of the extension. And I've gone and put all my points about an extension manager client into one bullet, discussion about this would be great; at least now I've written it out I understand better what it is I was planning so hopefully (providing someone doesn't find any flaws in my ideas) I might be able to start some coding. For now this will most likely have to stay as an extension as it will be too unstable to begin with, but hopefully once the project takes off it could be bundled in core along with a few common extension (which would then be able to be installed without configuration file editing due to this interface). Perhaps even, in the long run, the bulk of configuration could be moved into a configuration manager special page and validation classes -- this would certainly help many users. If anyone else would like to contribute to an extension manager (I've noticed a couple of other people interested on IRC) maybe we could set up an IRC channel and collaborate on it -- work out some UI mock-ups, design basic code, discuss ideas in greater detail etc. -- if not I'll work out some basic code that can then be expanded on or twisted as required by anyone who wants to help. Thanks, MinuteElectron.

Recently I volunteered to help establish a system for providing an extension manager\repository combination for MediaWiki.