User:Jeroen De Dauw/GSoC2010/Status

Introduction

My initial proposal was to create an extension management platform similar to what WordPress has. I send the first 2 months mostly doing research into how to best achieve this, and revised the project goals along the way. One of the first things that got dropped was doing configuration, as deployment on it's own is a big project. I checked out existing work in this area such as the Deployment Framework of Ontoprise and the new MediaWiki installer, and also implementations of other application level package managers such as PEAR and the stuff WordPress has. I ended up making some changes to the new installer and creating the Deployment and Distribution extensions. Distribution serves as a package and deployment metadata repository, that will be installed on mediawiki.org. Deployment is an extension that will provide the tools needed to update local MediaWiki installations and install new extensions. It's meant to be put into core once stable, so MediaWiki has out-of-the-box extension management capabilities at last.

Current work

I'm now working on creating an extension that will serve as a deployment repository on mediawiki.org, called Distribution. The idea is to first create a very simple version (not much time left in GSoC) that gets info via scripts going through the svn repo. Although this gets us only very basic deployment functionality, this will be a big win in installing extensions, and serve as a proof of concept.

After (and probably during) that, I'll work on the Deployment extension, to use the api provided by Distribution. After that the web interfaces (special pages) can be created, although this will definitely be for after GSoC.

Project results

See

External links

Presentation about this project at Wikimania 2010 - download slides
Deployment Framework

Plans 3.0

The goal now is to take on deployment for MediaWiki and extensions as a whole, as it makes little sense to have 2 separate systems with duplicate functionality, and integration issues. A lot of the work needed to have functionality similar to WordPress is already there, and simply needs to be adapted slightly to work in a more general system.

A rough draft of how I see the structure of the end product, and where the code is coming from:

Stuff we already have

Some of these things still require some work, but if they are here, it means the bulkload of effort is already done.

Web interface for the core installer (new installer chad has been working on).
CLI interface for the core installer? (not really checked this out yet, but appears to be there)
Core installer class with database install and upgrade capabilities.
Filesystem abstraction (I ported this from WP, mostly done, no testing done yet though).

Stuff that's still needed

Everything related to detecting updates, fetching packages and instructions, ect. The DF has some nice stuff that can be used here, so does WP. It's be nice to also have an abstraction layer here, so multiple mechanisms can be used here. An extension repository also needs to be set up, preferably on mediawiki.org.
Filesystem support for the installer, so it can be used to upgrade MW by clicking a button and then just fetching the new release and doing all the work. This can be achieved by creating the generic installer class and making the core installer inherit from it.
Extension installer class and the special pages that provide an interface to it.
Extension support for the core installer: installation and upgrade. This can be done by re-using the code of the special pages.
CLI support for extension management

Roadmap

This is the very loose planning I have right now:

Finish porting SSH2 filesystem abstraction class.
Get confirmation of Brion to go ahead with Plans 3.0 and get core access. (required for following steps)
Create installer class, adapt to core installer to work with this, and also create the extension installer class.
Take care of the fetching stuff.
Create the interfaces.

End product components

Core installer

The core installer should have all current capabilities plus

Upgrading of the filesystem from a fetched package
Install/update extensions that are detected

Special:Update

A page similar to the WP wp-admin/update-core.php

Checks for updates for both core and extensions, and shows update options for individual components, or the whole deal.

Special:Dashboard

A page similar to the WP wp-admin/index.php

A dashboard for administrators containing update information and fancy stuff like statistics.

Special:Install

A page similar to the WP wp-admin/plugin-install.php

On this page administrators can browse and search through extensions that are in the connected repository. This can be very basic to start with, but should eventually include filtering on categories and keywords, popularity, rating, ect.

Special:Extensions

A page similar to the WP wp-admin/plugins.php

A page listing all installed extensions, with options to uninstall, disable and upgrade them, as well as links to documentation, ect. Once MediaWiki has a configuration database, links to configure the extensions can also be included here.

CLI interface

It'd be nice to be able to do most stuff also via CLI, although I think the primary focus should be the web interface, as the vast majority of users will prefer that. The smwadmin.php tool from the DF can probably be adapted for this task pretty easily.