Let's for a minute forget about my code and look at what we want. From what I gather from the discussion:
* discover extensions available locally, base on some meta-file in each extension's directory. * Have a (web?) UI for listing the available extensions, and enable/disable them. * That would supposedly manipulate a list of active extensions stored in a file (or database table) * That list would have to be read and evaluated for each page request (it should probably be cache in memory, using the object cache or something) * any options the extensions may have would have to be set manually in LocalSettings.php. Since with the new system, extensions wouldn't load until after LocalSettings.php is evaluated, extensions would have to take care not to overwrite options when applying defaults.
This raises some questions
* In case of a web UI, how would it be protected? Would it be inside MediaWiki itself, available to, say, beurocrats? * When an extension is enabled by the UI, some custom script may be run to patch the db. That may require a different db user. * It would be nice to have a way to provide basic options to the extension on install, without having to edit LocalSettings.php
All of the above do not address how to locate and download extensions - which is what the code I wrote mainly does. I personally feel that it's nice to have a repository based installer, like, say, apt or something. So, I wrote something like that. How useful a CLI-based tool for this really is - well, it doesn't hurt to have it, I guess. It would be very convenient, but probably way too dangerous, to allow fetching extensions via a web interface.
In any case, *please* let's establish a repository of tgz bundles of extensions somewhere. It's simply silly to require people to use SVN to get extensions, unless they want bleeding edge. It's also trivial to do for all extensions that have their own directory. A simple script can generate something like this automatically: http://tools.wikimedia.de/~daniel/repository/extensions/
-- Daniel