[whatwg] Workers feedback

Ian Hickson wrote:
> On Fri, 8 Aug 2008, Jonas Sicking wrote:
>> So the API I'm proposing is the following:
> 
> This seems to be a strict subset of what the spec has now; the only 
> difference being that there's no easy way to create a worker and then pass 
> it to someone else to take care of, and there seems to be no easy way for 
> a worker to hear about a new "parent".

Don't really think it's a subset or a superset. The same feature set 
exists in both proposals, the syntax is just different.

The idea is that it's a simpler syntax for the common cases. However I 
think we'll have to agree to disagree what is "simple" at this point.

>> (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");

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? Note 
that there can already be other listeners to the port, so the port has 
been activated.

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? And that 
anyone else currently sharing that worker is going to break?

I would have expected sharing workers would always set up new message 
pipes. So here's my revised proposal:


[NoInterfaceObject] interface WorkerFactory {
    Worker createWorker(in DOMString scriptURL);
    Worker createSharedWorker(in DOMString name, in DOMString scriptURL);
};


interface Worker {
    boolean postMessage(in DOMString message);
    boolean postMessage(in DOMString message,
                        in MessagePort messagePort);

    MessagePort connectNewPipe();

    // event handler attributes
             attribute EventListener onmessage;
             attribute EventListener onload;
             attribute EventListener onerror;
             attribute EventListener onunload;
};

interface WorkerParent {
    boolean postMessage(in DOMString message);
    boolean postMessage(in DOMString message,
                        in MessagePort messagePort);
};

[NoInterfaceObject] interface WorkerGlobalScope {
    // core worker features
    readonly attribute WorkerGlobalScope self;
    readonly attribute WorkerLocation location;
    readonly attribute DOMString name;
    readonly attribute boolean closing;
    readonly attribute WorkerParent parent;
    void close();

    // event handler attributes
             attribute EventListener onunload;
             attribute EventListener onconnect;
};


The change from previous version is the Worker.connectNewPipe function. 
When that function is called, two entangled MessagePorts are created. 
One is returned from the function, and one is provided to the code 
inside the worker by firing a 'connect' event which contains the port. 
Note that calling createSharedWorker does not fire a 'connect' event.

/ Jonas

Received on Friday, 8 August 2008 11:35:42 UTC