What should I be aware of as a developer? That is, if I'm running a local MW and hacking on a resources (an extension / JavaScript / etc) will things Just Work? Or should I take active steps to disable Module Storage so that I don't inadvertently run the 'old' version of something I'm hacking on?
From what I understand, it's currently disabled by default, etc, so I don't have to worry yet. But I guess I'm asking in advance to ensure that it's well documented by the time we actually turn this on by default and developers have to think about it. --scott On Sun, Nov 3, 2013 at 8:27 PM, Ori Livneh <o...@wikimedia.org> wrote: > The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will > inaugurate the era of ResourceLoader module storage -- an era which > will be marked by terrifying and hilarious new bugs, intermittent > client-side failures, and generally inexcusable disruptions to user > experience. Sounds exciting? Read on! > > What is it? > ----------- > "Module storage" refers to the use of localStorage in ResourceLoader > as an auxiliary to the browser cache. ResourceLoader, remember, is the > MediaWiki subsystem that delivers JavaScript and CSS to your browser. > One of its primary functions is to minimize the total number of > network requests that your browser needs to make in order to render > the page, and to make the remaining requests as slim as possible. One > of the ways ResourceLoader does this is by making a list of all the > different components your browser needs and then transmitting them in > bulk. > > The downside of this approach is that a small update to MediaWiki's > code, touching perhaps one or two components, will often force the > browser to throw out (and re-retrieve) a bunch of unrelated modules > that did not change and did not ostensibly need to be re-retrieved. > This is because the browser cache operates on the level of network > requests; it is not intelligent enough to decompose a request into its > constituitive parts and to cache these parts separately from one > another. > > Starting with the 1.23wmf2 branch, ResourceLoader will check if your > browser implements localStorage, a mechanism for storing structure > data. If it does, ResourceLoader will use it as an auxiliary cache, > capable of versioning individual components. > > Why? > ---- > The primary goals are: > > * Destabalize MediaWiki's front-end code, by coupling it to an > inconsistently-implemented and poorly-understood HTML5 API. > * Make debugging fun again, by adding another layer of caching to > MediaWiki. Yes!! > > However, as with all new features, unintended side-effects are > possible. Specific concerns for module storage include the risk of > making the network footprint of page loads smaller, resulting in > improved latency. > > But seriously, > -------------- > * Module storage is enabled only if the underlying browser supports > localStorage (~89% of browsers in use, according to > <http://caniuse.com/#feat=namevalue-storage>). Users with older > browsers will not see a benefit, but they will not suffer a penalty > either. > * Module storage may or may not improve site performance. We need to > test it against a wide range of browsers and platforms to know for > certain. If it doesn't improve performance, we'll blame it on you, > your poor choice of browsers, and your uncooperative attitude, but > then we'll scrap it. > > How can I test it? > ------------------ > Glad you asked! Module storage is enabled by default on the beta > cluster, and on test & test2 wikis. The simplest way you can help is > by being alert to to performance regressions and front-end code > breakage. If you know how to use your browser's JavaScript console, > you can get stats about module storage usage on the current page by > checking the value of 'mw.loader.store.stats'. > > When the code is rolled out across the cluster, it will be disabled by > default, but you will be able to opt-in by manually setting a cookie > in your browser. I will follow up with the exact details. If module > storage proves stable enough for production use, we'll seek to asses > its utility by running a controlled study of some kind. If we can > demonstrate that module storage leads to a significant improvement in > performance, we'll enable by it default. > > --- > Ori Livneh > o...@wikimedia.org > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
