LocDB Maintenance Framework

General Concept
The maintenance interface for the location database must provide a full featured set of functionality for adding new locations, deleting locations and maintaining the data sets via a web interface.

It must be designed for use by all authors of all language versions. Except typical sysop operations like deleting locations, all features should be available to public. This means that the maintenance interface has to meet quite simular requirements as a wiki. We need all of the following:


 * Tracking of recent changes
 * Tracking of revision history
 * User authentification
 * User permission control
 * Tracking of user activity
 * Revision comparsion and undo

Furthermore, the handling of the maintenance interface should be as easy to learn as possible. Since all contributors to the location DB will be authors familiar with the wiki software, the acceptance will grow when the maintenace interface behaves as much as possible like a wiki.

For this reasons, it seemed to be a good choice to take the MediaWiki software as the base and modify it in order to implement all needed functionality.

Hacking MediaWiki
The goal of the framework of the maintenance interface it to integrate the maintenace interace into the MediaWiki software. Internaly, it offers a generalized API to the modules which themselfes never should need to deal with MediaWiki particularities.

The wiki software already provides most of the features we need, but not always in the way we would like to use it. At some points, it is enough to add a hook, in other cases deeper modifications of the original code have been neccessary.

Article text vs. HTML form
The wiki software is designed to maintain articles which consist of textes, but we need to maintain data sets. However, some parts of the wiki's article maintenace are still usefull for us. This are:


 * Tracking of recent changes
 * Tracking of revision history
 * Tracking of user activity

Other features had to be rewritten completely. Those are:


 * Revision comparsion and undo
 * User permission control, partly.

Additionaly, there had to be found a way to disable useless features like previewing or displaying a edit textarea when following a red link.

Internaly, the location pages are realized by a MediaWiki special page. It is hidden from the user by faking the Ldb: namespace. In fact, all requests to this namespace are internaly redirected to the appropriate special page at a very early state of precessing. In order to take profit of the usefull MediaWiki features in article revision management, dummy articles in the Ldb: namespace are created and modified in the background whenever a location is created or modified. Actualy, this dummy articles only contain random numbers and are never seen by the user.

One location with many alias titles
Users should be able to refere to a location with their prefered alias title. This seemed to be an important feature since most authors think in their mother's tongue and do not even know the English, or whatever, name for the locations they have to deal with.

This feature is a challange for developers. On the first few, it looks very much like the well know article redirects in the wiki. In fact, this is the way how it has been realized that each of the alias titles a location has leads to this location. The internel title of a location dummy article in Ldb: namespace always follows the sceme "Location " where is the internal DB ID. All alias titles are article redirects to the dummy article. This redirects are internaly added or deleted whenever an alias title for a location is added or deleted.

But htis is just the easier part of development. Whenever the title of a location has to be displayed to the user, we need to find out which of many possible alias titles is the prefered one for the current user. As long as the location's title has to be shown on a location's page, this works quite well.

Things get more tricky in entries of the recent changes, the revision history of an article, logs or whatch lists. The wiki software is not designed for displaying article titles and links to articles in dependence of user settings. What we have done is to store the internal location's title in this lists and postprocess them before they are displayed to the user. This is the price to pay if we don't want to completely rewrite the management for this lists. What makes things even harder is that entries in the recent changes and comments in revisions are stored as a static text string while log entries are stored in fragments from which the text string displayed to the user is built dynamicaly for each request. In order to cope somehow with this particularities, some deeper modifications in the MediaWiki code have been neccessary and the result is not always what could be called ideal. Stored locations may loss their aliases, e.g. when merging them. Then there is only one possiblity, showing the internal title. Of course, this is confusing for users.

Storing location revisions
Beside the revision list made by the wiki software, we also have to manage an own revision tracking system. The wiki software stores article textes for each revision of an article, but this is not suitable for our needs. Instead, we have to store data sets for each revision. There is an additional locrevision table that holds entries with location specific information. Furthermore, there is a table called moddata where all modules store their data sets in a serialized form whenever they are modified. Each row of the locrevision table referes to one or more rows of the moddata table from which the data set for each revision of the location can be extracted. The management of both, the locrevision and the moddata table, is completely done by the framework.

Comparing location revisions
When comparing two revisions, first of all both revisions are extraced from the locrevision and the moddata tables. The framework leads the data sets to the corresponding modules which do the actual comparsion. If neccessary, the modules are asked for their HTML outputs which are concatenated by the framework and displayed to the user.

Revison undo
Before the actual undo, two revisions need to be compared as described above. But this time, we don't need an HTML output. Instead, some kind of patch is calculated from the differnece of the revisions. This patch is tried to be applied on the current revision of the location. This process is very simular to how the standard tools diff -u</tt> and patch</tt> work on text files. If successfull, the difference between the current revision and the new revision is displayed to the user.

Merging locations
The current revisions of both locations are extracted from the locrevision and moddata tables. The appropriate modules have to find out whether there are merge conflicts or not. If none of the modules reports a merge conflict, the new revision has to be saved. Internaly, merging is implemented asymetricaly, i.e. one of both locations becomes the merged location and the other one is disabled. Special care has to be taken for alias titles. All or some of them have to be transfered from one location to the other and maybe some of the MediaWiki dummy article redirects have to be deleted. Furthermore, the revisions have to be moved from one location to the other in order to merge the revision history. A MediaWiki log entry has to be written. Additionaly, information about the previous alias titles, revisions and module specific data for both locations has to be stored in an extra table called merge_logging</tt>.