Requests for comment/Distribution and deployment





This project consists of 2 big steps. In the first the goal is to get the platform as far as possible without breaking any compatibility with current MediaWiki and extension code. The second step is then breaking compatibility by restructuring the way MediaWiki handles settings and extensions. The incompatible code will fork from the compatible one, so the platform can be used with current code, albeit with incomplete functionality.

Compatible stage
Both Configure and Ontoprises deployment framework already provide part of the needed features. Configure has gone as far, or almost as far as it can go without breaking compatibility, so the only work here for me is figuring out how it works, what changes are needed, and how to build on it. The DF works nicely, but lacks a GUI, which will need to be created. It also lacks several of the required features, which will need to be added. A big plus there is that Ontoprise is willing to support me in the project.

Features that need to be completed in this stage:


 * Automatic checking for extension updates (and updates to MW itself).
 * One click download and install option for extensions and extension updates.
 * Removal of installed extensions
 * Dependency and compatibility checking for all above steps
 * Enabling and disabling of installed extensions (so without removing them)

Non critical features that can be added later on:


 * Extension browsing
 * Recommendation of similar extensions
 * Showing a list of most used and most recommended extensions
 * Finding extensions by category or keywords
 * Extension packages support

Metadata source
The meta data about extensions and MediaWiki itself that is required for many of the above features needs to come from somewhere. The question of how to store and manage this data arises, which needs to be discussed before any concrete work here can be done.

The Ontoprise deployment framework gets this info via http from XML files, which are manually maintained. Another format might be preferred though. A possible approach is using Semantic MediaWiki on mediawiki.org, which would allow annotating information on extension pages in such a way it can be queried by a special web-service that communicates with the MW installations. This would be very practical since extension developers (and others) are then able to just edit wiki articles. Alternatives are having a special GUI coupled to a database where developers can log in and edit, or plain XML files editable somewhere (svn?) like the DF uses now.

This meta data source would be configurable so users could choose to view extensions from another extension provided then mediawiki.org. Important to note is that this stands loose from where extensions themselves check for updates, as this will be defined per extension, which allows to have complete functionality for extensions not in the extension repository your wiki is getting info from.

Incompatible stage
Here the way configuration is stored will change, both for core and extensions. This will require a changes to the code derived from Configure, but will also allow neater things at the side of the extension management. It might be possible to retain compatibility with the current system to some degree, but that depends on how the first stage will proceed.

TODOs that belong to this stage:


 * Rewrite the way MediaWiki (and extension) configuration is done from ground up, enabling awesomeness that's currently not possible.
 * Adapt the extension management to work with this, and possibly add features that could not be added without this.
 * Create conversion script where possible to migrate configuration of existing extensions and make it compatible with the new system.

Configuration
Defining setting info in a central place for extensions like Configure currently does is not acceptable. Extensions could have their own settings class, with methods to add new settings and override the values of existing ones - no more globals. This would also allow defining changes between versions, so settings can automatically be migrated when upgrading.

Some requirements:


 * The way configuration is handled needs to allow for layered configuration, so you can have a wiki farm with several global settings, setting groups and individual wiki settings.
 * Have compatibility with special WMF settings such as these. Initially the platform may lack this, but it should be possible to add it without any big changes to the platform core code.
 * Retain both database and file storage support, like Configure has now.
 * Performance! The final code needs to work on big wiki's.