Hey all,
I've run into some issues with storing revisioned configuration during the creation of the Contest extension and the upload campaigns functionality in the Upload Wizard, as well as in several other extensions. Since this issue appears to be a quite common, this email is intended to outline the problem and kick off discussion about how it can be resolved.
== Problem ==
Many extensions need some kind of admin UI in which non-user specific configuration can be done, ie creating contests or upload campaigns. If this configuration is just stored in some db tables created specially for this purpose, you do not have the ability to revert changes, restore deleted entities, simply compare changes, see who changes what and when, ect. This is quite problematic on big wikis, since someone can accidentally break a lot of functionality by deletion something, and then lack the ability to restore this. Or worse, if access to an account with sufficient privileges is obtained by a malicious person, he can modify configuration without this being logged anywhere. So what we need is to have similar versioning and logging for this kind of configuration as for wiki pages.
== Why wiki pages are not the answer ==
Historically, a few extensions have been storing simple configuration in wiki pages, typically in the MediaWiki namespace. Unfortunately there are several issues with this approach when it comes to more complex configuration, such as a contest. Since the data to be stored is an object, it needs to be serialized to fit into a wiki page. The general consensus here seems to be to use JSON.
Problem 1: querying the data. Since it's not stored in relational form, how are you going to get a list of active contests, or do any of the many other queries that are needed by the extension? One could solve this by not only serializing the data to a wiki page, but on every change, also update a redundant relational copy in the db. This is less nice though, because of the redundancy, and because you'd be looking at diffs of JSON instead of the changes to the single value you care about. So even though it would be a hack, you could go with this approach if not for problem 2.
Problem 2: no fine grained rights whatsoever. Contests should only be viewable by contest admins and contest judges, and only editable by the former. An approach that goes part of the way to providing this is putting each type of object (ie contest, upload campaign) into it's own namespace, and applying the needed rights restrictions on that. Since MediaWiki is not designed to prevent read access, I'd not be to eager to put anything that should not be accessible by non authorized people in there though. And this approach does not work at all when you need more fine grained restrictions, such as people with a certain right only being able to edit part of the configuration object.
And in the end, storing config in wiki pages is a hack, they where not designed to facilitate such usage.
== Request for Discussion ==
How would you go about creating a generic solution for storing revisioned configuration?
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --