Talk:Requests for comment/Extension registration

Drawbacks
Besides migration costs, what are the (potential) drawbacks of implementing this proposal? --MZMcBride (talk) 04:38, 24 May 2014 (UTC)
 * Parsing JSON is probably slower than loading a PHP file. We can mitigate this by caching the parsed result.
 * You can't use things like namespace constants in a JSON file. While this doesn't actually break anything (we can just use the actual number), it will hinder readability.
 * There are probably more, but that's what I can think of right now. Legoktm (talk) 04:50, 24 May 2014 (UTC)

Information conflicts with Composer
Considering we are almost definitely moving in the direction of Composer-managed extensions, it would be a good idea to not duplicate information in the composer.json file. Therefore, the "version", "url", "authors", and "autoload" keys should be removed. Since the composer.json file is also in JSON, it should be trivial to process extensions since it will be in the same folder. Parent5446 (talk) 04:47, 24 May 2014 (UTC)

Schema for info.json
I'd recommend writing a JSON schema for the info.json file, so that it is explicit moving forward what type of information will be in it. (It will make approving the RFC a lot easier.) Parent5446 (talk) 04:48, 24 May 2014 (UTC)

Caching of setup information
I would recommend doing some performance testing on this and see what impact this has for a large number of extensions. It may be worthwhile to "cache" the extension information by making a PHP file containing equivalent code. (In other words, have MediaWiki core take all the info.json files and dynamically generate a PHP file that would perform the equivalent configuration.)

Since the cache file will not change often, it can be held in the opcache and will be the equivalent performance of the current situation (maybe even slightly faster since it's including one file rather than one per extension.) Parent5446 (talk) 04:53, 24 May 2014 (UTC)

Some thoughts

 * info.json? That doesn't sound right, too generic and indescriptive. Why not something like extension.json?
 * What about when extensions aren't in $IP/extensions/? We allow extensions to be included from anywhere and we'll probably want to move even further in this direction by fixing extension assets to be per-path.
 * We still support PHP 5.3, "Add Extension name to list" -> "Set config var in LocalSettings.php" -> "Actually load the extension data containing global var info" looks like a register_globals vulnerability.
 * Where is description/descriptionmsg? Also it would be nice if we could physically code in a "If descriptionmsg is used the i18n message must' be defined within the extension itself and it must be using JSON i18n, not .php files". That requirement would allow a web based extension manager to display information about an extension without actually loading the extension or running any PHP from it.
 * The extension type is also missing.
 * The MassMessage/ in the module's remoteExtPath is redundant and also means the extension dirname is still restricted. Since this is now part of a context sensitive file it would be nice if the path settings were implicit/optional and the base path to the extension was automatically handled.
 * There should be a way to declare the minimum version of MediaWiki needed.

When I played around with ideas like these I went for something along the lines of this instead:

Of course I never picked specific names, MWExtension, load, loadFromPath, etc... are kind of just pulled out of a hat. But the method call meant the config load order and not being able to specify path issue never showed up. Daniel Friesen (Dantman) (talk) 07:54, 24 May 2014 (UTC)