0.2.0

[James Padolsey]

• Consider an operative.setReturnMode() to toggle between promises/direct/cb approaches. Right now it's all a bit of a mess.
• Implement a way to pass in dependencies ( #8 ). And in the fully degraded state, run the code in an iframe to avoid conflicts and to make it a more worker-like env.
• Deprecate direct-return in favour of using callback within operative methods. *
• This will make more sense, for consistency:

var op = operative(function(a, b, cb) {
  cb(a + b);
});

op(1, 2, function(r) {
  r; // => 3
});

NOTE: Non-undefined direct-returning from operative methods will still work but is deprecated and will be removed sometime in the future. So please move over to the new callback style, or, alternatively, promises.

[Evan Worley]

+1 - Sandboxed iframe with only the "allow-scripts" option

[James Padolsey]

I recently discovered that it's not possible to use importScripts within a worker that's created via a Blob. This is the method Operative uses to create debuggable workers.

Without importScripts I don't think it's worth operative trying to offer the dependency-loading feature. I guess, if you're looking to create a worker of such complexity then you should just avoid operative and use the worker API directly....

'Tis is a shame though.

[darsain]

Can't this be handled with a sort of dependency injection?

var op = operative(function (lib, method, args) {
  return lib[method].apply(lib, args);
});

op(_, 'unique', [ array_to_unique ],  function (unique_array) {
  // ...
});

And operative could maybe accept a dependency map as a second argument, which would make the object's in it accessible via function's this object:

var op = operative(function(arg) {
  return this.lib1.method(this.lib2.method(arg));
}, {
  lib1: lib1,
  lib2: lib2
});

op(arg,  function(result) {
  // ...
});

Dunno, just writing stuff from the top of my head :)

Anyway, the point of operative is a comfortable creation of workers without unnecessary http requests, no? So why do it with importing dependencies? I know I'd never want to do that. Creating a comfy API to inject dependencies makes way more sense.

[James Padolsey]

Dependency injection would be sweet but I don't think it'd be worth it.

It's not possible to share API access nor code (unless stringified and eval'd on either side) between a worker and its parent page.

The only way to do it would be via additional message-passing. So the worker would have to send an async instruction to the parent page like { call: '_.unique', args: [...] } and then the parent-page would run it there and send back the result. This'd have to happen repeatedly, and the lib code would just end up running in the main UI thread... so not really getting the full benefit of using workers...

[Evan Worley]

What do you mean you can't use importscripts in a worker created from a Blob? I've certainly done this, unless I'm misunderstanding? In fact I'm using importscripts with operative 0.0.3 currently.

On Jul 26, 2013, at 8:32 AM, James Padolsey [e-mail] wrote:

Dependency injection would be sweet but I don't think it'd be worth it.

It's not possible to share API access nor code (unless stringified and eval'd on either side) between a worker and its parent page.

The only way to do it would be via additional message-passing. So the worker would have to send an async instruction to the parent page like { call: '_.unique', args: [...] } and then the parent-page would run it there and send back the result. This'd have to happen repeatedly, and the lib code would just end up running in the main UI thread... so not really getting the full benefit of using workers...

—
Reply to this email directly or view it on GitHub.

[James Padolsey]

@evanworley Really? Which browser are you testing in? I've been getting a 'DOM Exception 12'? Waldron mentioned it a while ago https://twitter.com/rwaldron/status/27374027836

Not sure if it's still an issue but it doesn't appear to work. It may be related to BlobBuilder vs. Blob. I'll have a deeper look this weekend.

Maybe there is hope! :)

[Evan Worley]

I'm testing in Chrome (latest) on Linux. That might be the case with BlobBuilder. Before operative my code was using a Blob (via the Blob constructor) and then making a worker by

new Worker(window.URL.createObjectURL(blob))

Can we avoid using BlobBuilder if it does have this restriction? importScripts is a critical feature for us, and probably a lot of other people who are doing anything other than academic exercises with Workers.

[Evan Worley]

Plus see https://developer.mozilla.org/en-US/docs/Web/API/BlobBuilder "Note: The BlobBuilder interface has been deprecated in favor of the newly introduced Blob constructor."

Is the BlobBuilder just a fallback of some kind?

[Deniss Alimovs]

I'm using importScripts with the current version of operative. It definitely works. DOM Exception 12 is thrown when you provide a relative URL to importScript so make sure it's absolute.

[James Padolsey]

Branch under development available here: https://github.com/padolsey/operative/tree/0.2.0

I'll be revisiting the importScripts thing soon -- and any added dependency feature will be included on that branch.

@evanworley:

Is the BlobBuilder just a fallback of some kind?

Yep, it's a fallback atm. See the code here. Anyway, I think in my tests I was using a relative URI -- that was the likely issue (as @denzo mentioned).

[James Padolsey]

0.2.0 Merged.

Dependency declaration implemented, now you can do stuff like:

// Create interface to call lodash methods inside a worker:
var lodashWorker = operative(function(method, args, cb) {
    cb(
        _[method].apply(_, args)
    );
}, [
    'http://cdnjs.cloudflare.com/ajax/libs/lodash.js/1.3.1/lodash.min.js'
]);

lodashWorker('uniq', [[1, 2, 3, 3, 2, 1, 4, 3, 2]], function(output) {
    output; // => [1, 2, 3, 4]
});