[whatwg] Workers feedback

[Ian Hickson]

On Fri, 8 Aug 2008, Jonas Sicking wrote:
> 
> I.e. we wouldn't allow a Worker to be passed to postMessage, but the 
> object returned from myPipe.port1 would be allowed.

I strongly disagree with the idea of making communication channels with 
workers be a "second class citizen" in terms of being able to send 
communication channels about.


> > The whole point of ports as an architectural concept is that they 
> > provide an opaque interface, and who exactly is on the other side is 
> > not something that you should need to have any information about.
> 
> Why do we need this feature? I.e. why is it useful to have an abstracted 
> MessagePort where you don't know who you are communicating with?

It is a critical component of any capabilities granting mechanism.


> My proposal makes Workers behave the same way as Windows when it comes 
> to sending messages.

That's the problem. The Window communication mechanism is a pretty crappy 
one -- it's a single channel, there's no delegation, if you want to 
connect two windows who don't know about each other you have to proxy, 
etc. If it wasn't for the fact that everyone is implementing it, I'd 
really be pushing for changing to a more capable (and more secure) system, 
something much more akin to message channels.

(I originally came up with postMessage() years ago, I have learnt much in 
that time about how message passing mechanisms should work.)


> > > Exposing a MessagePort as a permanent property, like the global 
> > > 'port' property, has the downside that that object can potentially 
> > > die if the MessagePort is ever passed through postMessage somewhere.
> > 
> > Do you mean that:
> > 
> >    var w = createWorker('worker.js');
> >    otherWindow.postMessage('here is the worker you asked for', w.port);
> >    w.port.postMessage('oh i wanted to talk to you after all');
> > 
> > ...would fail? (It would return false from the last call.)
> 
> Yes.
> 
> Further, the fact that a clone is created on the other end rather than 
> the same object I think can be confusing. I.e. if I set an expando on a 
> port the receiver of the port won't see the expando. This is required 
> since otherwise we'd have synchronous communication between threads, but 
> I think it's confusing to authors. This is why I generally don't like 
> MessagePorts and think that they should be used as little as possible.

I disagree, but I don't know what I can say to convince you. All I can say 
is that the original impetus for the message channel mechanism came from 
authors who wanted a more capable messaging mechanism.


> Also, I would have expected the above to throw an exception. Having it 
> silently fail (which is what'll happen if you don't check the return 
> value) seems likely to cause hidden bugs.

Throwing an exception seems a little drastic, but I could be convinced to 
change that -- the problem is that there's no way to know if it's going to 
throw (or return false) before the call. Which is better?:

   if (!p.postMessage(msg)) {
     // it went away
   }

...or:

   try {
      p.postMessage(msg);
   } catch (e) {
      if (e.code == 20) {
        // it went away
      }
   }

...?

Consider also that the postMessage() might not be critical, e.g.:

   // this code runs when the user asks to save his work
   for each (var p in registeredNotifiers) {
     // registeredNotifiers is a list of ports to parts of
     // the codebase that want to be notified just before
     // something is saved
     p.postMessage(msg);
   }
   doSave();

If the author doesn't check for the potential exceptions (which at the 
time of writing he might not be expecting, since he doesn't know if anyone 
is ever going to be doing something with the ports that would cause an 
exception to be possible here), then the saving doesn't work. If we just 
return false, then the error is ignored, which is likely fine here.


> > I don't think this is a big problem. I mean, it's like being worried 
> > that references into a window fail to have the right effect after the 
> > window is closed or navigated.
> 
> I think for windows we are usually saved by the fact that generally when 
> a window is navigated, all the code that uses that window is killed.

Not if it's in another window. I think it's very much the same problem.

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