Re: Shared workers - use .source instead of .ports[0] ?

On Tue, 10 Apr 2012 19:33:55 +0200, Andrew Wilson <atwilson@google.com>  
wrote:

> I'll agree that having to use ports[0] to access the MessagePort in a
> connect event has always felt a bit like an API wart. However, I don't
> entirely recall why we wanted to have the connect event use the
> MessageEvent interface. So I'd be uncomfortable with changing connect  
> event
> to not match that interface without understanding why we made those
> interfaces match in the first place (perhaps Ian can chime in here).

I don't see the problem with using MessageEvent for connect.

> I'll also note that the MessageEvent for cross-document messaging has a
> |ports| attribute, so I'm not certain why removing this attribute on the
> connect event "makes it closer to the [cross-document messaging] API" -  
> can
> you clarify your reasoning here?

The code you write looks more like in cross-document messaging:

// cross-document messaging:
// I can get a message event from several places
onmessage = function(e) {
   // post a pong message back
   e.source.postMessage('pong', '*');
}

// shared workers:
// I can get a connect event from several places
onconnect = function(e) {
   // post a pong message back
   e.source.postMessage('pong');
}

The author doesn't need to care that e.source are different objects in the  
two cases, they only need to care that it exposes a postMessage method  
that they can use to communicate back.

> Also, since MessagePort is not a
> WindowProxy, I'm not sure we want to encourage developers to treat them  
> as
> the same by putting them both as the |source| attribute in MessageEvents  
> in
> different contexts, especially since the postMessage() APIs don't  
> precisely
> match.

Hey, we use MessageEvent in lots of different contexts with different  
semantics -- cross-document messaging, workers, shared workers,  
EventSource, WebSocket... I don't think making this change to shared  
workers is going to invalidate the usage of MessageEvent.

On Tue, 10 Apr 2012 19:47:12 +0200, Andrew Wilson <atwilson@google.com>  
wrote:

> To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs
> changed to support object transfers after we defined the connect event
> structure, so it's not unreasonable that we should take another look at  
> the
> connect event to try to make it match the current definition of
> postMessage().
>
> I think the model of connect event we've used in the past
> (pre-structure-clone-transfer) is as if the creator of the SharedWorker
> were sending a message like so:
>
> postMessage("", [newPort]);
>
> The recipient then receives a MessageEvent with data="" and  
> ports=[newPort].
>
> In the new world where postMessage() supports a transfer object, I think
> the appropriate analogous connect event would be to result in a
> MessageEvent with both the |data| and |ports| attributes pointing at an
> array containing a single MessagePort. I don't think putting the
> MessagePort as the source attribute is the right model.

I don't think authors think of it in this way.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 11 April 2012 05:25:24 UTC