Topic on Talk:Requests for comment/Configuration database

Below are the raw notes from our discussion at Wikimania 2013:

• consider moving defaults to a serialized format?
  • nasty case -- default is dynamic based on other configuration (especially something like $wgServer, which is initialized rather late during setup)
  • default installs should be workable in the core database only (no FS access), but we'll want CDB files or something for high-scale rollouts like Wikimedia!
  • nasty case -- the default might be a list, to which the actual config wants to add (or replace it). This requires the defaults to actually be applied in LocalSettings.php
• kill the global namespace vars? or keep them for back-compat? or....
• ..... no cookie-licking! let's kick the RFC into shape to where anybody who has the time can implement it (even if outside wmf)
• should we start on new config bits only? or include the existing globals so we have a migration path for them, and then deprecate/kill later?
• we should be opportunistic... maybe dovetail with some project that can use the config db and push it into core starting with that, then move things in?
• startup performance & access performance are REALLY IMPORTANT ON THIS! memory usage may be important as well
  • ^- pluggable storage, not just arrays. Need to hack out some specs for thre quirements on this. <- may need 'hybrid' storage, such as CDB on filesystem for most Wikimedia stuff but a few settings in local database
  • what config can we safely expose via api? (parsoid can use this etc)
  • note that we have maint scripts for getting config info (eg for admin scripts to use), this sort of model should still work
    • avoid reading the config databases directly from other languages (like a python script), read it through MediaWiki so its pluggable storage always works
    • note: avoid turning into a general key-value store. try to keep it configuration-related!
    • consider the config _store_ as a prereq for config _ui_. (though for example wikia kinda cheated, and there's the old Configure extension... but these are scary :D)
  • EventLogging (and several other extensions) use memcached for managing JSON blobs of configuration across wikis.
• avoid access to settings as global state, instead pass individual settings or a task-specifc settings object. Any code accessing a global setting/singleton essentially becomes impossible to unit-test.

Based on my current ideas, I think the answers to your questions are as follows:

• I think we should use something like JSON. Then it's human readable, easily parsed in PHP, and not something scary like serialized PHP.
• I think we'll need a back-compat mode for awhile that allows importing/exporting of globals. We've got over 10 years of extension history that we don't want to gratuitously break.
• Agreed. I think breaking it into concrete steps/phases make it way more likely for this to succeed. For example, here I went ahead and started making configuration more portable.
• I think it should be opt in, as some config is going to be easier to migrate than others. This is easier with back-compat I mentioned above
• Once the initial framework is in place, it'll be very easy for any person with commit access to migrate other settings--99% of them will just be copy+replace usages.
• Agree with this
  • Yeah.
  • I'm paranoid and always figured we'd do whitelisting.
  • especially on backend being pre-req for UI. In theory, once the backend is stable the UI a separate project to start building.
• I think it makes the most sense to be in Contexts, see my gerrit change linked above