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

Hi All - I created bug [16730] to capture this question/issue.

The CfC to publish a CR of Workers started on April 4 [CfC], the same 
day Simon posted his question [Head]. Since there were no objections to 
the CfC and a solution to this issue is likely to be backward 
compatible, I intend to move forward with the CR transition request 
using the latest ED of Workers as the basis. If the resolution of this 
bug is substantive (e.g. from the perspective of implementations), that 
will likely require an additional LC->CR cycle. Nevertheless, my 
preference is to not block the CR on this issue. If anyone has any major 
concerns about proceeding this way, please speak up as soon as possible.

-Thanks, AB

[CfC] 
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0047.html
[Head] 
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0049.html
[16730] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16730

On 4/11/12 1:41 PM, ext Ian Hickson wrote:
> I'm fine with making changes here. The following proposals seem to make
> the most sense, though I'm sure others could work too:
>
>   1. Leave it as is.
>
>   2. Make the .source attribute be of type (MessagePort or WindowProxy)?
>      and add the port to .source, also leaving it in .ports[0].
>
>   3. Make the .source attribute be of type (MessagePort or WindowProxy)?
>      and add the port to .source, making .ports null.
>
>   4. Set the .data attribute to the port, leaving it also in .ports[0].
>
>   5. Set the .data attribute to the port, making .ports null.
>
>   6. Use a new event object instead of MessageEvent.
>
> For back-compat, 1, 2, or 4 seem best.
>
> For similarity with posting things to other windows, 2 or 3 seem best.
> However, I think the similarity is a bit shallow in practice.
>
> For similarity with how messages are handled elsewhere in Workers and when
> using MessagePorts in general, 1 and 4 seem best.
>
> For cleanliness of code, any of 2-6 seem best.
>
> For consistency acros codebases on the Web, 1, 3, 5, or 6 seem best.
>
> If you count each of these considerations as being of equal importance,
> then options 1, 2, 3, and 4 all come out equally good.
>
> Right now the only actual implementation argues for 1, I believe.
>
> I think if I were designing the API from the ground up today I would do
> either 3 or 6. I think with back-compat concerns I would probably
> compromise by going for 2.
>
> Best way to convince me is to ship what you want. :-)
>

Received on Friday, 13 April 2012 13:41:30 UTC