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.
3. 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