[whatwg] Workers feedback

[Ian Hickson]

On Fri, 8 Aug 2008, Jonas Sicking wrote:
> > > 
> > > (We might want to add an onconnect property to WorkerGlobalScope, 
> > > but it doesn't seem strictly needed)
> > 
> > How else would you connect to a shared worker?
> 
> That is done at an application level. For example:
> 
> worker = createSharedWorker("foo", "bar.js");
> worker.addEventListener("message", handler, false);
> worker.postMessage("wassup dude, i just connected");

How would the worker distinguish that from the original "parent" sending 
the same message?


> Actually, it seems like onconnect as defined in the current spec has a 
> race condition. The shared worker example does the following:
> 
>    var worker = createSharedWorker('worker.js', 'core');
>    function configure(event) {
>      if (event.message.substr(0, 4) != 'cfg ') return;
>      var name = event.message.substr(4).split(' ', 1);
>      // update display to mention our name is name
>      document.getElementsByTagName('h1')[0].textContent += ' ' + name;
>      // no longer need this listener
>      worker.port.removeEventListener('message', configure, false);
>    }
>    worker.port.addEventListener('message', configure, false);
> 
> However what's to say that the 'connect' event hasn't fired inside the 
> worker before the 'worker.port.addEventListener' line executes?

Doesn't matter. MessagePorts queue up messages until they receiver either 
sets onmessage or calls start(). (This is explained just below the 
example.)


> Note that there can already be other listeners to the port, so the port 
> has been activated.

The port only activates if you set onmessage or call start(). Calling 
addEventListener() doesn't activate it.


> Also, what MessagePort object is handed to the connect event if the 
> inner or outer port has been handed through postMessage somewhere? I.e. 
> if someone does:
> 
> var worker = createSharedWorker('worker.js', 'core');
> someIframe.postMessage("here's your worker", worker.port);
> 
> Does that mean that noone can ever share that worker again?

The createSharedWorker() call always creates a new pipe to hand to the 
'connect' event.


> And that anyone else currently sharing that worker is going to break?

Why would it break anything? I'm confused.


> I would have expected sharing workers would always set up new message 
> pipes.

It does.


> So here's my revised proposal:

Now it's even more complicated, while still not doing everything that the 
current proposal does. I'm not at all convinced this is better.

Is the only problem you have with the current design that it is too 
complicated?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'