WIP: WebWorker support

[alanpearce]

I created a plugin to load a module as a worker, and modified curl.js to work from within a worker.

There isn't any detection for worker support right now, which is the biggest missing feature for me.

There are a few ways I thought of to do this:

• The most obvious way (to me) would be to just require the file as normal in the worker plugin, perhaps using setTimeout to fake asynchronicity. I'm not sure if this is a good idea though.
• Alternatively, a shim module could be added, to check for window.Worker and return Worker, whether it's fake or real.
• Do something with has!, loading a non-worker module instead if the browser doesn't support Workers.

Currently I've done the bare minimum to get it to work, suggestions for improvement are certainly welcome.

[alanpearce]

Now curl works from inside a worker. define doesn't, yet. Given the use of the worker plugin I think it would make more sense to use define instead, although it might be difficult, given that curl's define doesn't work outside of the curl context anyway.

[alanpearce]

curl.baseUrl from inside a worker is relative to the worker's directory. This might surprise people when using curl to spawn a worker in another directory.

The workaround I'm using right now is to set baseUrl to '/', since it was previously unset. I'm not sure if something should be done about this, or just have it documented somewhere so that people are aware of it.

[unscriptable]

wow! This is a great start.

I'm thinking that the web-worker support in loadScript could be injected via a shim. Does that make sense? Then again, this is such a small amount of code. Hm.

importScripts is sync? That seems lazy of google. :P

[alanpearce]

I'm not quite sure I understand what you're referring to with the shim idea. Do you mean something like adding a def.worker for loadScript to check for? If that's what you're after, where would you suggest putting it? createResouceDef? fetchResDef?

As for importScripts being synchronous, that did surprise me. From reading the draft spec, it sounds as if browsers will fetch the scripts asynchronously but execute in order. I'm not sure how easy it would be for us to take advantage of this though.

[unscriptable]

I meant like the ssjs shim: https://github.com/cujojs/curl/blob/master/src/curl/shim/ssjs.js#L66

[alanpearce]

Ah, I see. That does look like a better approach. I'll look into it.

[alanpearce]

It wouldn't make sense to put a shim in a different file as curl wouldn't be able to load the shim file without the shim.

However, I could define one of two definitions of loadScript in curl.js based upon a similar predicate. That way, it would only be tested once per page load and once per worker and still be more modular than it is now.

[unscriptable]

I was thinking like this: https://github.com/cujojs/curl/blob/master/dist/curl-for-ssjs/curl.js

The ssjs shim is pre-bundled into that version of curl.js. Does that make sense? What do you think?

[alanpearce]

Aha. Now I understand. I'll give it a try this weekend and add a make rule for it like the ssjs one.

[unscriptable]

cool!

[alanpearce]

The compiled version seems to fail when built with with ADVANCED_OPTIMIZATIONS at the first line of the original loadScripts function. It seems to work fine when built with --NONE, so I'm not sure if I've done anything incorrectly or not.

[asilvas]

@alanpearce Hi Alan, unrelated to curl, I've found ADVANCED_OPTIMIZATIONS will generally be an issue unless you compile all code into a single JS. It heavily renames everything for optimizations, so unless it knows about all references, it cannot safely work.

[alanpearce]

@asilvas Thanks for the info. There error is caused by a reference to window.document, as neither window.document nor window are defined. Workers have a different global scope to scripts running inside a webpage, see the spec.

It wouldn't make sense to compile the code for window.document into curl.

[alanpearce]

@unscriptable Would you like me to rebase this against dev as well? I was planning to rebase it anyway when complete to remove the unnecessary commits.

[unscriptable]

Yes, please rebase on dev. Thx!

[alanpearce]

Thanks for the hints!

[alanpearce]

Closing in favour of #130

[alanpearce]

I think I broke it.