Last modified: 2013-10-25 11:53:00 UTC
Some more CPU intensive client side multimedia tools may need to do background processing in the future. Browsers support running JavaScript background processes through the Web Workers API -- https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers However there are some complications: * workers run in their own JS context, so the JS file loaded must be self contained * worker source code must be loaded from the web page's origin, which could be problematic when RL is being used on a second domain such as bits. There may be workarounds such as using blob URLs... Note that workers communicate with the parent page through post message similar to iframes.
+1. Unsorted brain dump follows. If we're already inside a Worker and want it to fetch code: We could use postMessage to communicate with mw.loader and have it deliver the implementation of the module instead of executing it in the parent page. Since implementation are nicely self-contained it should be relatively straight forward (it has a reference of the closure which can be stringified and evaluated elsewhere). I've been thinking about a different feature that warrants similar handling, namely storing/caching of modules in localStorage. The tricky part is that some modules, especially in debug mode, return one or more urls instead of a closure. So we'd need to fetch those inside the worker presumably (the raw url type of resource executes immediately without a closure), however a Worker can't have a cross-domain injection like <script> can in the parent page. Anyhow, we could ban those modules initially and debug mode would simply not work in its current form (though I've been thinking about ridding debug module as it is and replacing it with sourcemaps instead, debug mode causes too many problems). Alternatively we could instead require the worker logic to be a module of its own, so instead of trying to fetch from mw.loader within a worker, we could say something like mw.loader.loadInWorker( .. ) which create a Worker instance and give it a url to load.php and a special parameter that makes load.php respond without the mw.loader.implement closure, and resolve dependencies and in the right order server-side.
Telepathy! I knew about this bug in 2011: https://github.com/atdt/wob.js
I like the 'mw.loader.loadInWorker([module, ...])' idea -- that's a logical mapping to 'new Worker(url)' and means that using workers is an explicit opt-in that shouldn't complicate general module handling. Could either skip mw.loader.implement and ensure modules are ordered correctly in the Worker-mode output, or could tack an RL loader stub onto the beginning of the combined module -- either way should work I think. But to get the load.php contents loaded up in the first place, we either need to use a cross-domain XHR and blobify it, or we need to force the worker modules to be loaded from load.php on the local domain. The latter is simplest, but I don't know if we can rely on that working in production environment.
Change 89375 had a related patch set uploaded by Ori.livneh: WebWorker ResourceLoader Eliza wat https://gerrit.wikimedia.org/r/89375
Change 89375 abandoned by Ori.livneh: WebWorker ResourceLoader Eliza wat Reason: A joke, obviously. But it works. :P https://gerrit.wikimedia.org/r/89375
