Experimenting with the WorkerPool API

[Aaron Boodman (Google)]

I had some ideas about improving the WorkerPool API and did a little mockup. This is a JavaScript wrapper around the existing WorkerPool that exposes a nicer API.

Download: http://youngpup.net/z_dropbox/worker2.zip
Test: http://youngpup.net/z_dropbox/worker2/test.html

Basic features:
* Worker code can now rely on other js libraries
* Worker errors are automatically propagated out to the environment
* Messages are now named (you send and register to receive them by name) and support complex JSON-compatible arguments

Thoughts?

Summary:
===========================================================================
Example main js:
===========================================================================
var w = new Worker2();

// Load the worker with a couple javascript files.
w.load(["util.js ", "fib.js"]);

// Register to receive the "result" message.
w.setMessageHandler("result", function(arg) {
  alert("fib result: " + arg.result + " took " + arg.time + "ms.");
});

// This is optional. If you don't set the onerror handler, the error
// will just get thrown.
w.onerror = function(msg) {
  alert("fib error: " + msg);
};

// Send the fib message with an argument. Any JSON-compatible argument will
// work.
w.sendMessage("fib", 100);


===========================================================================
Example worker js:
===========================================================================
// Register to receive the "fib" message.
google.gears.workerParent.setMessageHandler ("fib", function(n) {
  var result = 1;
  var prevResult = 0;
  var t0 = new Date().getTime();

  while (n > 0) {
    var temp = result;
    result += prevResult;
    prevResult = temp;
    n--;
  }

  var time = new Date().getTime() - t0;

  // Send the result back to the parent. Note that we can send complex
  // objects.
  google.gears.workerParent.sendMessage("result",
                                        {result: result,
                                         time: time});
});

- a

[Muthu Ramadoss]

WorkerPool is one area where we need such frameworks. Nice work, keep
it going.

///////////////////////////////////////////
IntelliBitz Technologies
http://training.intellibitz.com
044 22475106
trai...@intellibitz.com
http://groups.google.com/group/etoe
http://sted.sourceforge.net
http://www.slideshare.net/intellibitz
///////////////////////////////////////////

[bribus]

Hi,

i used your wrapper to handle many things in my app, it's a great job
but i have a problem :)
The most important thing you did is for me that you allowed us to use
external files in workers (your getLib() method retrieve the code of
such files)
but you are using xmlHttpRequest to do it so, and currently i'am
having a problem with this, when my app is "disconnected" (i mean
datas,scripts are in cache) and my webserver is stopped, the worker2
try to retrieve datas through the xmlHttpRequest object and it looks
like with this method the localServer can't intercept the request and
serve local cached files so remote server doesn't answer and the
worker2 crash.

If i'am wrong or anything else please notify me. If you have solutions
i'll take :p

Thank you for the job

See you

Clément

[Aaron Boodman]

LocalServer should be able to intercept requests from XMLHttpRequest.
Are you sure that the URLs you are requesting match exactly what has
been captured?

- a

[bribus]

I think yes, this problem occurs with the first lib loaded by the
worker2 (ie json.js)
To match my dirs i changed this in the worker.js file :
this.libs_ = ["http://localhost/webdev/OffWeb/libs/worker2/json.js",
"http://localhost/webdev/OffWeb/libs/worker2/worker_context.js"];

This file is is the urls list of the files to capture, (same url) and
in the storage directory of the local server i can see "
json[14515].js "
So i guess the file is captured, and the url is the same.

Anybody experiencing the same type of things overthere?

Clément

On 5 juil, 11:09, "Aaron Boodman" <a...@google.com> wrote:
> LocalServer should be able to intercept requests from XMLHttpRequest.
> Are you sure that the URLs you are requesting match exactly what has
> been captured?
>
> - a
>

[bribus]

Maybe i have a clue

in your xhr.js file:

doRequest method:
Only you can tell me but this piece of code will add the
current timestamp to url as parameter. And since nothing should be in
opt_params (as long as i know) the url should be : urlVar + ?
r=timestamp

// To prevent browsers from caching xhr responses
opt_params['r'] = new Date().getTime();

url += "?";
for (var n in opt_params) {
url += n + "=" + opt_params[n];
}

But when i print the url var in the console im seeing 2 parameters, r
(what is the timestamp) and " toJSONString " when contains code.
Maybe it can trouble the localServer when XmlHttpRequest tryes to
access to this sort of file?

Thank you by advance

Clément

[bribus]

Without this parameters (and after cleaning the browser cache to be
sure answer isn't coming from browser cache)
your worker retrieve the library files with xmlHttpRequest.

but why the file can't be find when adding parameters.... if anybody
knows ;)

Thank you
Clément

[Aaron Boodman]

Ah yes, I borrowed that xhr.js from Gearpad, where it is used
transmitting application data and caching would be very bad. The
timestamp is there to ensure that it doesn't happen. The best thing I
believe for this case would be to remove it.

On 7/5/07, bribus <bribu...@hotmail.com> wrote:

> but why the file can't be find when adding parameters.... if anybody
> knows ;)

It can. See the "ignoreQuery" property, here:
http://code.google.com/apis/gears/api_localserver.html#manifest_file

But again, the best thing is probably to remove that bit of code from
xhr.js. Good find!

- a

[bribus]

Ok, i removed that part yesterday and it worked perfectly, your worker
wrapper is very useful for my app.

Thanks for the "ignoreQuery" hint, i'll look it this morning.

Have a good day ;)

Clément

On 5 juil, 17:19, "Aaron Boodman" <a...@google.com> wrote:
> Ah yes, I borrowed that xhr.js from Gearpad, where it is used
> transmitting application data and caching would be very bad. The
> timestamp is there to ensure that it doesn't happen. The best thing I
> believe for this case would be to remove it.
>

[neyric]

Great ! I'm just missing a feature i'm trying to add : do XHR from the
worker.
The worker has to send a message to the parent thread that does the
request and send back the result to the worker.
It schouldn't be hard to implement on top of your code...

For those who, like me, use YUI :
Here is a hack to replace the doRequest function from the xhr.js file
using YUI :

function doRequest(method, url, postData, callbackFct) {
var successFunc = function(o) { callbackFct(o.status, o.statusText,
o.responseText); };
var xhr = YAHOO.util.Connect.asyncRequest(method, url, { success:
successFunc}, postData);
return function() { YAHOO.util.Connect.abort(xhr); };
};

Don't forget to include : (or from your server...)
<script type="text/javascript" src="http://yui.yahooapis.com/2.2.2/
build/yahoo/yahoo-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.2.2/
build/connection/connection-min.js"></script>