Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson <atwilson@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?


On Fri, Jun 3, 2011 at 5:25 PM, Dmitry Lomov <dslomov@google.com> wrote:
>> >> If you want a quicker way to transfer all messages of given types, see
>> >> my previous mail: { transfer: ArrayBuffer }.
>
> (sorry I somehow missed your previous mail when replying)
> I do not think filtering by types solve much.

It solves the "very large transfer list" performance question, though
it hasn't been shown whether that's an actual problem.  It also allows
writing functions like postMessageTransfer(port, obj) {
port.postMessage(obj, { transfer: [ArrayBuffer] }); }, without having
to do the recursion yourself to find the ArrayBuffers.

(Dmitry: I'm receiving each of your mails twice; once from
dslomov@chromium.org and once from dslomov@google.com.)

On Fri, Jun 3, 2011 at 5:54 PM, Kenneth Russell <kbr@google.com> wrote:
>  b) Leave the "MessagePort[] ports" property. Filter out all
> MessagePorts from the incoming Transferables[], and have only them
> show up in the ports array on the other side.

FYI, this is the same as what I described earlier.
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0812.html
(second paragraph)


On Fri, Jun 3, 2011 at 6:02 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> e) Keep "MessagePort[] ports" the way it is but deprecate it.

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

I agree that it'd be great to be able to pass MessagePorts around like
other objects.  I havn't had to use them with any complexity yet, but
the current mechanism seems cumbersome for moving more than one port
around at a time.

-- 
Glenn Maynard

Received on Friday, 3 June 2011 22:23:41 UTC