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.
--