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

On Tue, Apr 10, 2012 at 1:06 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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?
>

That's fine with me as well. To be honest, I haven't been closely following
the Transferable discussion, so I wasn't certain what the semantics of the
|data| and |transfer| attributes were (
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#messageport).
If it's valid to just have |data| point directly at a Transferable rather
than a-map-containing-Transferables then that's fine by me.


>
> 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
>