Modular registry of components

A couple notes off the top of my head while it's on my mind...

Currently we have centralized "registry" lists of various components:

• Configuration variables
  • includes/DefaultSettings.php
• Class files
  • includes/Autoloader.php
    • $wgAutoloadLocalClasses
• API modules / class files
• JavaScript class files
  • includes/Autoloader.php
  • $wgJSAutoloadLocalClasses
• Special pages
  • includes/SpecialPage.php
    • SpecialPage::$mList
• Database updaters
  • maintenance/updaters.inc
  • $wgUpdates
• Parser functions
• Media handlers
• Maintenance scripts
  • maintenance/Maintenance.php
    • Maintenance::$mCoreScripts

etc

Components for extensions get added to these lists, or to some adjunct list which is combined with it, from the setup in the extension's main file.

And of course we have the localization files centralized as well for core components.

This centralization is kind of a pain:

• new modules touch more distributed pieces of code
• merging an extension into core requires switching around where we list it

In contrast, skin classes are autodetected at runtime from the skins/ folder, in theory to make it easier to drop new ones in... but since the skins/ folder is part of core we now discourage putting things directly there, and have provision for extension skins which... need to be manually added to LocalSettings.php. :P

What I'd like to see

• Easy way to isolate a component in its own directory, containing its class->file maps, special page registrations, parser function registrations, maintenance script registrations, localizations, etc.
  • Extensions and modules in core shouldn't have to be too different.
    • Ideally, developing nearly _all_ modules as "extensions" and just bundling them into our distribution should be the way we work on most things
• Efficient way to auto-detect available modules that are present in our installation directory
  • Note this might mean we want to cache combined registrations actually in use
• Some provision for a configuration database which lets us enable/disable modules at runtime without changes to the core LocalSettings.php family.
  • If something is not enabled, we should never actually run any code from it though we may need to look at it when scanning for available modules.

Possible implementation ideas

• module info in PHP arrays
  • recommend against this -- code execution might be convenient but could lead to silly recommendations
• module info in formatted comments in head PHP file
  • WordPress does something like this, I think. Nice as it doesn't require any extra files.
• module info in specific XML/JSON/YAML/etc file

• store cached info in memcache/db?
• store cached info in local FS?