I suppose I have a foot in each camp here.
Ryan Lane wrote:
ParserFunctions is an amazing example of this. MediaWiki simply doesn't work without ParserFunctions. You can tell me it does, and that people can live without it, but I refuse to believe that. We get support issues extremely frequently that end in "install ParserFunctions".
I wrote ParserFunctions under protest, and I hoped at the time that it would not be essential or widely used. That's why it was an extension. Maybe the time has come to merge it in.
I also wrote the ImageMap extension, which some might argue should be integrated.
Aryeh Gregor wrote:
Partly this is a matter of preference. I personally write things almost entirely for core -- I've never written an extension, so my only extension commits are to things that other people wrote as extensions.
I agree that there is an element of personal preference. Brion was certainly in favour of putting lots of functionality in extensions, and, like Trevor, used the argument that at some point in the future, extensions will be easier to install and/or bundled with core releases. Brion wrote the Poem extension, for instance, which is easily as trivial as Trevor's ArticleEmblems extension.
My view is somewhat more moderate. I think that:
* Trivial, uncontroversial things like EditWarning should be in the core. * MediaWiki should be usable without extensions, some basic set of functionality is required. * Complex functionality, large code size, complex installation and external dependencies are all arguments for splitting a feature out to an extension.
Trevor Parscal wrote:
In response to recent comments in our code review tool about whether some extensions should be merged into core MediaWiki, or not. I would like to try and initiate a productive conversation about this topic in hopes that we can collaboratively define a set of guidelines for evaluating when to move features out of core and into an extension or out of an extension and into core.
I think there is a need for judgement, and a definitive set of guidelines will be difficult to produce.
- Noting that "so-and-so said I should integrate this into core" is not going to magically absolve anyone of having to stand behind their decision to proceed with such action and support it with logic and reason.
Yes, however, community consensus should be respected. The logic and reason you've been expressing in this thread does not appear to be particularly more convincing than anyone else's.
Aryeh Gregor wrote:
- It's easier to understand how core code works in the absence of
extensions, because the code is explicitly written out where it occurs. When extensions are involved, you have a wfRunHooks() line in core, which basically means "absolutely anything could happen at this point". When you run into a hook when reading code, it doesn't only complicate understanding how the code will run in practice, it also makes it much harder to change. If you want to refactor, you have to write a lot of painstaking and ugly logic to preserve the semantics of the hooks, or else just give up and get rid of them.
I agree with this. The point of modularity is to separate concerns, and a hook-based model is opposed to this. A well-designed modular architecture has a simple, well-documented interface between the modules. Some of our extensions are a long way from this.
Nowadays I prefer adding object-oriented extension interfaces, which work by having the extension subclass a core base class. See for instance MediaHandler, FileRepo, LBFactory and PoolCounter.
Trevor Parscal wrote:
And what about javascript and css files? What about messages? Generally speaking lots of the MediaWiki PHP code is modular, but it's the rest of the stuff that goes into making a feature work that is not. Extensions bundle this all together, and that proximity makes maintenance and review easier.
There are security problems with having web-accessible files like JavaScript and CSS in the same directory as non-web-accessible files like PHP includes and command-line scripts. Perhaps the resource loader will fix this, and we'll be able to organise such files by module in the future.
There is a significant performance advantage to splitting up messages by language. However it is possible to have module-specific message files in the core -- we have one now for the new installer.
-- Tim Starling