r64451 MediaWiki - Code Review archive

Could you please create a separate minification extension? That way these functions can be used by any number of projects.

As Tim mentioned, the idea is to make this a core supported component.

Could you point me to the mention? I talked to him about OutputPage-specific items.

I think this is part of a larger js2 branch discussion. The minifcation functions are tied to the outputpage specific methods. These classes should be part of core js support improvement hence these class loaders should be in the core AutoLoader not an extension.

If it helps the deployment process it would be pretty easy to remap things into an extension but this is the fist time that idea is being communicated to me.

Gotcha. Here's my understanding:

The OutputPage modifications are needed in core and their integration is top priority after release.

Any other functionality should be put into modules so that it can be more easily deployed and keep the core to a minimum.

oky ... it would be pretty trivial to make mwEmbed work as an extension. Traditionally if many extensions use some component of an extension its been better to put that in core and hence mwEmbed was originally set to be part of core ... but if easier from a deployment path perspective to have a few lines of code in an extension php file rather than in core thats pretty easy to move over, and then people could just express the dependency?

If thats an agreed upon direction from Tim and Trevor, its pretty easy to make it into an extension and have it run with trunk.

But in the end the idea is to have the mw js library as something that every mw js developer can depend on being available so we don't have 5 different ways to get msgs into javascript or load and minify javascript classes. We want to maximize the ease of use and sharing of all the jquery plugins and libraries, so that one just has to issue a short mw.load call to have instant access to all the javascript libraries components they could possibly need across user scripts and extension development.

This dove tails into issues with the present extension system lacks dependency resolution or clean installation process.

Another potential issue is that having it non-core could slow adoption but clearly that point is mute relative to deployment process since that is clearly a much bigger slowing factor.

I'm a bit confused on what the right thing would be here.

On other websites sites, minification and script-loading aren't easy to separate from any level of the site. They will affect how you write code, and how you deploy code. They aren't so easy to mix and match.

If we only had Wikimedia projects to think about, the obvious thing would be to pick one strategy and go with it all the way. But I'm not sure what the right policy is for MediaWiki, as we probably shouldn't be making deployment decisions for the world.

If you really want minification and script loading to be optional modules, then they will have to be able to run without any configuration in the modules themselves (no loader.js, no extern.js), and probably be much less efficient and useful. That might the price we pay, but to me it feels like too much of a sacrifice.

Or, you could mandate that minifiers and script-loaders have to work without configuration, but work better with it.

Still, it is a scary idea if performance-minded extension writers have to start adding multiple configurations to their extensions, for various kinds of minifiers or script loaders.

I think the right thing to do is to minify and gzip by default with configuration variables to control that if they need be and ofcourse only have one supported method for adding scripts to the page.

Not sure what you mean by be able to run without any configuration in the modules themselves.. The main reason module loaders are to be in JS instead of in php is because you don't have a consistent platform to target. Different browsers have dramatically different feature sets. So while one browser may need hundreds of lines of iframe proxy system another one supports native html5 cross domain messaging.

Having the loaders in js is also nice in the long term, since eventually we can let the browser keep track of its state / interface. Instead of having php output a custom list of scripts for each page, for each logged in user, you have a single per-user, per-page cached configuration json object and you can achieve high cache hits across page views. ie your interface is driven via dynamic script-loading rather than custom script lists dynamically outputed via server php hits.

All shared interface code and page specif vars, non-php content is still outputted and cached via php similar to anonymous user page views. The point is you don't have /User:userName/monobook.js script list killing your cache for every logged in user on every single page view.

by "non-php content" I meant "article content"

long since resolved by separate extension, and now the resource loader being added to core.