Thread:Talk:Requests for comment/Configuration database/Notes from Architecture meetings/Wikimania 2013

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.