On Fri, Jun 3, 2011 at 4:15 PM, Andrew Wilson <atwil...@google.com> wrote: > > > On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard <gl...@zewt.org> wrote: >> >> On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson <atwil...@google.com> wrote: >> > significant motivation. The stated motivations for breaking this API >> > don't >> > seem compelling to me given the existence of backwards-compatible >> > alternatives. >> >> This proposal is backwards-compatible. If the argument is an array, >> nothing changes, so postMessage(..., [ports]) is equivalent to >> postMessage(..., {ports: [ports]}). (The array-only approach can be >> done compatibly, too; the object version is just an alternative to >> that.) What's backwards-incompatible? > > Ah, I missed that piece (to be honest, I haven't been following this > discussion in every detail - I only chimed in because of Jonas' request for > implementation feedback). > >> >> For anyone not looking closely at the IDL while reading this, this >> means deprecating (for whatever value "deprecate" has on the web) the >> ports array in MessageEvent--not the ports parameter to postMessage >> (that's a sequence). > > Does this affect the API for the SharedWorker onconnect message as well?
Good point; that might inform not deprecating the ports array in MessageEvent, but leaving it as is. -Ken