- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 10 Apr 2012 13:06:03 -0700
- To: Andrew Wilson <atwilson@google.com>
- Cc: Simon Pieters <simonp@opera.com>, Jarred Nicholls <jarred@webkit.org>, "public-webapps@w3c.org" <public-webapps@w3c.org>
On Tue, Apr 10, 2012 at 10:47 AM, 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.
Why make .data be an array containing a single MessagePort? Why not
just make .data be the MessagePort object itself?
The .ports property is basically a relic of the time before we had
Transferrable objects. Even if we all end up implementing it, I think
we should let authors ignore it once they don't care about down-level
browsers.
/ Jonas
Received on Tuesday, 10 April 2012 20:07:04 UTC