On Wed, Apr 11, 2012 at 10:41 AM, Ian Hickson <i...@hixie.ch> 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. :-)
Shared workers is on our radar, but I don't have an ETA for when we'll ship it. I suspect we'll go with 2 or 3 once we do ship. / Jonas
