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. :-)
