Last modified: 2012-07-20 07:33:53 UTC
After all, these things change relatively rarely, so moving them to a separate module would noticeably reduce the size of the startup module.
Just be careful, because you will notice that the mediawiki module which is loaded first (with jQuery) depends on a variety of configuration variables. If these configurations are made into their own module, they need to be a raw module and be loaded before the mediawiki module, similar to jQuery.
So it won't reduce the size of the to-be-parsed amount of scripts. As the loader framework requires these configuration variables. I briefly discussed this with Max during the Berlin Hackathon 2012. His primary concern wasn't the data itself but the cache fragmentation. Right now we've got it set up like this I believe (example for mediawiki.org): * Startup - Hardcoded in the HTML (the only script link hardcoded in HTML) - Version parameter: None (shouldn't be since it is hardcoded in the page cache) - Cache age: 5 minutes - URL: https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&* * Core modules - Only if isCompatible() returned true - Loaded from ResourceLoaderStartupModule - Contains the core library of jQuery and mediaWiki - Version parameter: Yes - Cache age: ∞ (30 days in practice) - URL: //bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20120528T141202Z By moving mw.config to the second request we reduce the amount of data put into the "every 5 minutes" loop. However that does introduce a problem that has to be solved, which I believe was the reason mw.config was put into startup in the first place: Version parameter. Configuration comes from many places. We need a highly reliable timestamp for this. Assuming for the minute that we can come up with such a reliable source of timestamps and max() them. Is it worth it? Is it worth it to invalidate the core-modules request every time the configuration changes? This would mean that every time LocalSettings.php (or in the case of WMF, most files in wmf-config) changes the cache for jquery and mediawiki will be invalidated. The alternative would be to put them in a separate group, but that doesn't work. In order to use groups in the loader one needs to have the actual loader, and it can't load itself. So we'd have to add a separate document.write just for mw.config?
I think I need to be convinced that there is a problem here. The startup module is pretty small, and the benefits of being able to push things out site-wide in 5 min is worth a lot. Theoretically there is a size that the startup module could reach that would begin to be questionable, but I am not so sure we've gotten there yet. I think a much better solution would be to add per-module configs so extensions can stop polluting the general config. Per module configs could be configured as a list of variable names to export or functions to be called which return an array of key and value pairs which can be added to the module's exported configs. It can all still be added using mw.config.set so migration would be easy. This could reduce the future strain on the global config which has a short expiry, and these configs could be part of the module's dependencies, so when they are changed the module is automatically invalidated - similar to how we do this for editing a file or message the module depends on.
Wontfix for now. Could be reconsidered later if it is actually a problem. Right now it may appear redundant, but it is actually serving a purpose and 5-minute deployment guarantee is quite important and being relied on. If and when we are going to use ESI inside caching (or something similar) then this becomes obsolete as we will not invalidate the startup module in 5 minutes but only when it changes. Right now we can't do that because the startup module can't give itself a timestamp to load it, and putting it in the HTML means cache fragmentation as well as pollution and inconsistency (basically all the problem from before ResourceLoader). With ESI:include this becomes a possibility again because it will be separate from the overal cache and thus centrally purgeable.
