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/

Trevor Parscal wrote: I know I mentioned this in a CodeReview comment, but I'll mention it again here: http://mediawiki.org/wiki/List_of_extensions_to_be_merged_to_the_core I think developing a set of guidelines for this issue might be nice, though I'm not sure there's really all that much disagreement about what should and shouldn't be in core currently. MZMcBride

2010/9/22 Trevor Parscal &lt;tparscal(a)wikimedia.org&gt;rg>: Making MediaWiki more modular won't magically make it possible (or even desirable) to write any old feature as an extension. Some things will still have to go in core and some things we'll simply /want/ to put in core because making them extensions would be ridiculous for some reason. It's true that more modularity will lower the difference in awkwardness between doing certain things as extensions vs. in core (and is generally desirable), but I also don't see how it would make (much) lighter work of adding extensions to core: most extensions should either be easy to add to core (Vector and WikiEditor for instance, any special page extension) or cause some bumps because they were written in an awkward way to begin with, probably because it'd have been better to put them in core. Roan Kattouw (Catrope)

On 22 September 2010 13:52, Chad &lt;innocentkiller(a)gmail.com&gt; wrote: Note from the perspective of a tarball user: yes please. Though code management may be much more sensible with things organised into the extensions folder, having a basic set of extensions included by default in the tarball would be most helpful to the sysadmin whose user just asked for a new wiki. (I'm thinking by analogy with operating systems - a "base" set of extensions which are a good working set to start with, but which you can strip right down to "core" if you really want to.) - d.

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

I'd rather have MediaWiki build on some classes & object instances with a clear responsibilities, Inversion of Control and possibility to test each _object_ separately without causing interference to other components. Discussion what's core/extension is to me secondary. Maybe at some point "hooks" as we know them will not be needed, we could be able to use interfaces as provided by the programming language instead of hooks, possibly (yes, I'm dreaming) tied together by something like PicoContainer. Even still, those interfaces *will* change and it would be good if developers could refactor the code in the core and extensions at the same time. I don't why we really duplicate so much functions even within core (API vs. standard special pages for example). But that's probably the issue to be solved in phase4 :) So before asking how much to add into core, maybe we should first clean up some, and then possibly add. Or sometimes adding something (like a proper multi-wiki configuration management $wgConf++) may clean up and simplify some things inside core. //Marcin

Chad wrote: DumpHTML was also split from core. texvc should have been moved out of core, but since that would change things set there from the mwbeginning, nobody did it yet. I think the point is to start shipping mediawiki with common extensions there.

Op 29 sep 2010, om 01:15 heeft Platonides het volgende geschreven: Yeah, that sounds good ! Perhaps the new installer could contain that as an option during the inital setup. Like a two or three-column thing with a bunch of checkboxes. Language: English [\/] Default theme (X) Vector (_) Monobook (_) Foobar Common Extension: [X] ParserFunctions [X] SpecialInterwiki [X] Cite.php [X] CharInsert [X] CategoryTree etc. you get the idea -- Krinkle

This is great if we are going to version the extensions with the version of MediaWiki shipped, and backport changes to those extensions to ensure they get security and bug fixes like core does. Alternatively, we could provide a way for extensions to be easily upgraded to compatible versions, similar to wordpress and other sane applications. If we don't plan on doing one of two things, then we are forcing our users into the crapshoot that is finding the correct extension version, or possibly running insecure or buggy extensions. Respectfully, Ryan Lane