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

Requirements
--84.154.197.178 14:44, 26 February 2012 (UTC)ons specific to a wiki
 * Should work cleanly for one-off installs
 * Should handle Wikimedia-style farms:
 * global configuration
 * configurations shared among project groups
 * configuraakd sjdsfjs dandsnda fnd
 * 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

 * bool
 * int
 * string
 * email
 * URL
 * local path
 * message key
 * other
 * 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 strings
 * array of items

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