Requests for comment/Configuration database

Problems to solve

 * .php config files are fragile
 * easy to break by mistake
 * no edit history unless you explicit do external version control
 * Editing config files is difficult/inconvenient for many sites
 * requires shell access
 * can't easily expose limited settings to admins on the wiki, making serious bottlenecks for site config issues on a big wiki farm
 * Handling config for multi-wiki farms right now is very difficult
 * SiteConfig/InitaliseSettings stuff is weirdly Wikimedia-specific and just plain ugly
 * querying settings from a sister site (even simply translating dbname <-> URL and getting descriptive names) is very difficult, unreliable (various settings may be in CommonSettings and not show up in the config arrays)
 * extensions are difficult to configure since the array is read in before the extensions and their defaults are loaded
 * Many, or most, config options can be readable for the public or wiki users, since they're no secrets. Yet wiki owners may wish not to publicise some specific settings even if that was not a security risk. At least in large wikis, holders of different rights may be wanted who can alter different config settings but not all (e.g. a bureaucrat may enable or disable extensions but neither see not alter database passwords)
 * Have a special page listing all config settings that are viewable be the current user as per their group rights.
 * Allow wiki admins to assign viewing and altering rights to each config setting, groupwise or individually.

Counter-arguments

 * Users can help with site config issues by making recommendations; they can use Extension:ViewFiles to view the config files and say exactly what they want changed. Then all that is needed is for a site admin to make the change.
 * There will always have to be a configuration file at least for database credentials (e.g. $wgDBname) that MediaWiki needs to access the table with the configuration settings.
 * The config files are suitable for developers who want to tinker without having to go through the steps of changing the database. It's quicker to comment out configuration settings than to go to a configuration screen to change them. This is especially true if the names, structure (e.g. array vs. string), etc. of the configuration settings are rapidly changing as the code evolves.
 * If the configuration gets messed up to the point that one can't even get to the configuration screen (e.g. suppose access to the configuration screen is inadvertently restricted to a group of users with no members), it's easier to edit a config file than to find an alternative way to change the database and thereby restore the system administrator's access to the configuration screen.

Requirements

 * Should work cleanly for one-off installs
 * Should handle Wikimedia-style farms:
 * global configuration
 * configurations shared among project groups
 * configurations specific to a wiki
 * need to be able to fetch config info from other wikis cleanly
 * Varying user permissions; not all settings should be editable by everyone
 * Metadata...
 * For each config (core or ext) provide:
 * type
 * validation rules
 * friendly name
 * more detailed description, examples
 * Default
 * Needs high-level read/write support, so we can abstract backends more easily (CDB,SQL,etc)


 * Possibly use HtmlForm or similar framework for defining UI paging? Similar to prefs rewrite?
 * We can adapt some of the form field types in Configure (that's where I got the idea for HTMLForm) for the new configuration (there are some specialist types like group permissions arrays).


 * Allow XML, JSON, or YAML config files?
 * Model off of Zend_Config, maybe.

Data types

 * boolean
 * number
 * text
 * email
 * URL
 * local path
 * message key
 * wiki reference
 * wiki-id needs decoupling from $wgDBname
 * Be able to get a db connection (just like wfGetDB) for a remote wiki. Or an API url, if we don't have DB access)
 * array of any date type in this list other than 'array'
 * array of any date type in this list other than 'array'

Internal interface
Common case: local lookups:
 * (shortcut)

Other-local-site info lookups:

User interface
There's a lot that can be adapted or copied from Configure.

Bugs that could be solved / New features

 * bug 12518 - Cross-wiki userrights reflects groups on local wiki, not target wiki
 * Maybe add a iw_wiki col in the interwiki table that references the wiki ID:
 * bug 11 - Red interwiki links -- check for page existence across wikis
 * bug 9890 - Reasonably efficient interwiki transclusion
 * (these sorts of things benefit from being able to look up things like remote namespaces cleanly, so we can pull data from a db directly instead of doing some nasty api hack)
 * Drop $wgLocalInterwiki and check if iw_wiki == wfWikiId.
 * Maybe run internal HTTP requests (transwiki imports, fetching remote file description page, interwiki transclusion) internally?
 * Drop $wgLocalDatabases and replace this with a query in the database.
 * bug 7750 - Extension for storing non-default $wgGroupPermission's in MySQL table