Now that the responses on this thread have slowed, I would appreciate if
the participants would please summarize where they think we are on this
issue, e.g. the points of agreement and disagreement, how to move
forward, etc.
Also, coming back to the question in the subject (and I apologize if my
premature subject change caused any confusion or problems), since we
have an open CfC (ends June 9 [1]) to publish a Candidate Recommendation
of Web Messaging, is the Messaging spec going to need to change to
address the issues raised in this thread?
-Art Barstow
[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
On Jun/3/2011 8:47 PM, ext Kenneth Russell wrote:
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
