-----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.
MinuteElectron schreef:
- One of the earliest problems I encountered was providing a systemfor 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).
Maybe have a directory filled with config files that get loaded automatically?
Roan Kattouw (Catrope)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roan Kattouw wrote:
MinuteElectron schreef:
- One of the earliest problems I encountered was providing a systemfor 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).
Maybe have a directory filled with config files that get loaded automatically?
That's a possibility, and probably a good idea. While using the database seams like a sexy solution but I've been quite weary of using it given it's tendency to become unstable, the fact that the data would have to be serialized, and possible opposition by Wikimedia tech (syncing configuration could become a nightmare and you probably don't want it on the database servers anyway -- many hundreds more queries). Such a system that could do this might also be a solution to allowing web-based MediaWiki configuration.
Thanks, MinuteElectron.
MinuteElectron writes:
-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfdlGoACgkQkJvUlhoE3wSEWQCgt4NQuEJuNIVKJUKo4Z9itOEk cAYAn2WMTMrfz7dtwUgI9PjFrLs6qk+P =QsBY -----END PGP SIGNATURE-----
Don't we have it as maintenance/installExtension.php? --VasilievVV
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
VasilievVV wrote:
Don't we have it as maintenance/installExtension.php?
While that serves a similar purpose it works entirely differently. That scripts requires shell access, it requires the extension files to have already been uploaded to the server, does not provide a user friendly interface and in most cases does not assist configuration.
What an extension manager\repository combination would provide is a user interface that even less experienced users could use allowing them to install and configure extension from a wide range of sources, rather than being forced to download from subversion and manually configure via LocalSettings.php. This would also reduce the chance of erroneous user input by moving configuration to a variety of validation systems designed with ease of use in mind.
MinuteElectron.
MinuteElectron wrote: <snip>
Recently I volunteered to help establish a system for providing an extension manager\repository combination for MediaWiki.
Hello,
Have a look at https://addons.mozilla.org/ , maybe the mozilla foundation can help us on this ?
As for describing extension, you can have a look at mozilla developer center for some ideas :
http://developer.mozilla.org/en/docs/Bundles http://developer.mozilla.org/en/docs/install.rdf
Once you know how to describe an extension, you will be able to put them in a repository and in the end write an extension manager.
For the repository, I think Firefox extensions are validated by Mozilla each time they are updated.
cheers,
wikitech-l@lists.wikimedia.org