On 22/09/10 05:34, Trevor Parscal wrote: <argument #2 against merging> That is probably the most important point. It ease code review, any new comer can easily understand code. What about shipping the Mediawiki release with some of the best extensions ? You do not need to actually merge them with trunk, just chip mediawiki + some extensions preconfigured. Hooks in the installer would let user tweak the configuration. I had a little script which, given a revision number would : - installed trunk and stable branch - copy my favorite extensions in the extension folders - append to local settings my extension configuration files <snip> Would you move as extensions : squid support, math, languages, external stores, external auth, API, chinese support, Tidy, Antivirus ... They are all awesome features but not necessarily needed in core. -- Ashar Voultoiz % mv hashar /mw/extensions/

On Tue, Sep 21, 2010 at 11:34 PM, Trevor Parscal &lt;tparscal(a)wikimedia.org&gt; wrote: I don't think anyone's commented on the former (everyone's been talking about pushing in, not pulling out). IMO, the conditions for splitting something into an extension A) Not a lot of people use it anyway (hard to gauge) B) It probably shouldn't have been in core in the first place (eg: AskSQL) So far, the only successful case I can think of offhand for splitting an extension out was AskSQL, but it's a perfect example of what should happen. I think this also makes a good case for keeping something in core and not removing it. If we need to add 6 new hooks to keep it working, then it might be best to keep it in core (single purpose hooks are lame) Quick note on the installer. It only enables extensions that already reside in your extensions folder. Since we don't distribute any with the default package, this might not be terribly useful. More awesome is Jeroen's GSoC work on extension management. Something to look at post-1.17 branch though. If enough people say so ;-) -Chad

On Tue, Sep 21, 2010 at 11:34 PM, Trevor Parscal &lt;tparscal(a)wikimedia.org&gt; 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. Other people prefer to write extensions instead of core features. As long as the code gets written and works either way, I don't think it's usually a huge deal. A lot of stuff will work fine either in core or as an extension -- this doesn't have to be made a religious issue or one where we have detailed official policies. What I think is clear is that anything that the large majority of MediaWikis would benefit from should be enabled by default, which given our current setup means it has to be in core. I haven't looked closely, but I believe this includes a significant part of the usability stuff (although not all). MediaWiki should work as well as possible for as many users as possible out of the box, and whatever that implies for how the code is structured is what we should do. I cannot conceive of any reason why most of the features of the Vector extension should not be in core, for instance -- why would you *not* want them? Why would you ever want to disable them? ("Admins should have choice" is not a good reason by itself. Cf.: http://weblogs.mozillazine.org/bz/archives/020683.html) Other than things you want to enable by default, here are some reasons to put some features in core rather than extensions: * Core features are much easier for site admins to enable than extensions. It would be great if this were fixed, but currently, it's not, so it can't be dismissed. You can dismiss this reason (basically your #1) as soon as it's become irrelevant in practice, but not before. * For smaller features, it will take a lot more code to write them as extensions than as part of core. You can often add a useful core feature in less than ten lines of code -- extensions are much heavier-weight. This is unavoidable, because extensions have to have a whole bunch of metadata to specify where their code executes and so on; with core code you can just put it in the right place. * 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. On Wed, Sep 22, 2010 at 4:33 AM, Trevor Parscal &lt;tparscal(a)wikimedia.org&gt; wrote: This can be accomplished by regular old object-oriented programming. Keep all the related code in one class, and make as much possible private so that classes can only call a limited number of well-defined, well-documented, easily-understood entry points. I don't think extensions are a good model for this -- to the contrary, they're antithetical to modularity, since any extension can drastically change how any part of the program behaves (given enough hooks). On Wed, Sep 22, 2010 at 10:17 AM, Andrew Garrett &lt;agarrett(a)wikimedia.org&gt; wrote: This is reminiscent of COMEFROM. It makes it really hard to understand what's going on if you have the code scattered everywhere. Modularity is great, but it needs to happen along clear boundaries to keep the code comprehensible -- not "anything can happen at this point".

I suppose I have a foot in each camp here. Ryan Lane wrote: 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: 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: I think there is a need for judgement, and a definitive set of guidelines will be difficult to produce. 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: 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: 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