User:DanielRenfro/ExtensionRepo

These are notes about implementing a package management system for extensions &mdash; spawned by a discussion at the Ask the Developers session at Wikimania 2012.

Rationale
Mediawiki has a robust system for implementing extensions, but currently lacks an integrated mechanism for managing them. Currently installation, management and dependency-resolution is done manually, usually by a sysadmin or a staff member. While knowledgable users (with command-line access) can keep the extensions managed, it seems like there should be an integrated solution.

One imagined implementation of this project would be a set of special pages where users (with the appropriate permissions) could browse extensions, install and configure them, among other actions. Mediawiki.org could serve as a repository, or a standalone Mediawiki instance could be setup specifically for this purpose.

Thoughts on client-server model
At first this project was imagined as in a client-server context, with two separate extensions providing the functionality for each. It was assumed that there would be a centralized repository for extensions, and clients (Mediawik installations) would consume extensions being served from the server. But the question arises: "Who manages the extensions on the server and where to they come from?" The repository would most definitely be an instance of Mediawiki itself, with some functionality added to turn it into an extension-repository. Each repository would need another repository of it's own to install extensions &mdash; this is a recursive problem with no solution. It would defeat the purpose of this project to not allow the repository to manage its own extensions. Therefore, it was decided that the code for this project must cover both client and server functionality, allowing repositories to manage their own extensions.


 * Question
 * If all repositories are remote (not local,) where does a repository get its extensions?


 * Answer
 * Repositories can be local. Allowing Mediawiki installations to both server and consume extensions. (By default the repository functionality is turned off, but can easily be turned on with a single configuration setting.)

The solution was a simple segregation of the idea of installation with the idea of activation. If all installed extensions are immediately active, repositories cannot host extensions without activating all of them. If, however, installation is separated from activation, any Mediawiki instance can act as both a repository -- activating only those extensions that are needed.

Features / deliverables

 * dependency & compatability resolution
 * (requirement) rigorous security and error-checking
 * both GUI and command-line interface
 * configure the extension upon installation, and then again whenever you feel like it
 * integrated tests for compatibility
 * logging
 * (requirement) security!!!
 * (requirement) don't break the current extensions
 * permissions (possibly a new role, group, etc.)
 * flashy Web2.0 interface that makes people go "Ooooo"
 * API modules
 * distributed nature &mdash; any package can be installed from any repository
 * automatic and manual checking for extension updates (and updates to MW itself)
 * extension browsing
 * recommendation of similar extensions
 * show a list of most used and most recommended/highest rated extensions
 * keyword search with an option to limit by extension-version/compatability-with-current-MW-version
 * enable and disable extensions without uninstalling them

"It'd be cool if..." features

 * an Extension: namespace (NS_EXT) that's filled with auto-generated pages about each extension, somewhat like 's Extension namespace
 * provides a place to view information, urls, versions, rate the extension, leave feedback (?), etc.
 * one-click installation
 * a better Special:Version section
 * feedback on extensions in the form of
 * ratings (1-5 stars?!)
 * comments
 * ability to fork w/link to source code (github or tarball or other)
 * downloading class that supports:
 * resuming, timestamp checking, parallel downloads, cached file validation
 * FTP user limit autodetection
 * file://, ftp://, http://, https://, scp://, ftps://, ldap://, etc.
 * easy way to upload a new version of your extension to a repository (api?)
 * special page for configuring mediawiki itself

Benefits

 * one-stop-shop for managing extensions
 * wiki admins/sysops can also administer extensions without command-line access/knowledge
 * faster than doing it manually
 * should cause people to run more updates (especially if a notification system is built in)
 * recommended extensions for new sysops
 * more visibility for extensions and extension developers
 * easier to configure existing extensions

Subpages

 * /Technical