On Tue, 10 Apr 2012 19:33:55 +0200, Andrew Wilson <[email protected]>
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 <[email protected]>
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
