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

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.

-atw

On Tue, Apr 10, 2012 at 10:33 AM, 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'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? 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.
>
> -atw
>
> On Tue, Apr 10, 2012 at 5:27 AM, Simon Pieters <simonp@opera.com> wrote:
>
>> On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls <jarred@webkit.org>
>> wrote:
>>
>>  On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters <simonp@opera.com> wrote:
>>>
>>>  On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking <jonas@sicking.cc>
>>>> wrote:
>>>>
>>>>  Sounds great to me. The ports attribute is basically useless except in
>>>>
>>>>> this
>>>>> one instance since ports are these days expose as part of structured
>>>>> clones.
>>>>>
>>>>> Avoiding using it in this arguably weird way in this one instance seems
>>>>> like a win to me.
>>>>>
>>>>>
>>>> I'd like to have an opinion from WebKit and Microsoft about this
>>>> proposal.
>>>> Can someone comment or cc relevant people, please?
>>>>
>>>>
>>> FWIW this to me seems like a good improvement to the intuitiveness.
>>>
>>
>> OK. To make things clear, are you OK with making this change in WebKit?
>>
>>  Since
>>> a MessageEvent interface is being used, qualifying that *source*
>>> WindowProxy
>>>
>>> is populated is all that's needed?
>>>
>>
>> It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
>> IDL for MessageEvent's source member would need to change type from
>> WindowProxy? to object?.
>>
>>
>>
>>>
>>>> cheers
>>>>
>>>>
>>>>  / Jonas
>>>>
>>>>>
>>>>> On Wednesday, April 4, 2012, Simon Pieters wrote:
>>>>>
>>>>>  Hi,
>>>>>
>>>>>>
>>>>>> In Opera Extensions we use something that resembles shared workers.
>>>>>> One
>>>>>> modification is that the 'connect' event's source port is exposed in
>>>>>> .source instead of in .ports[0], to make it closer to the API for
>>>>>> cross-document messaging. Maybe we should make this change to Shared
>>>>>> Workers as well.
>>>>>>
>>>>>> I think shared workers hasn't seen wide adoption yet, so maybe changes
>>>>>> like this are still possible.
>>>>>>
>>>>>> What do people think?
>>>>>>
>>>>>> currently:
>>>>>> onconnect = function(e) { e.ports[0].postMessage('pong') }
>>>>>>
>>>>>> proposed change:
>>>>>> onconnect = function(e) { e.source.postMessage('pong') }
>>>>>>
>>>>>> --
>>>>>> Simon Pieters
>>>>>> Opera Software
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Simon Pieters
>>>> Opera Software
>>>>
>>>>
>>>>
>>
>> --
>> Simon Pieters
>> Opera Software
>>
>>
>