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

On Thu, Jun 2, 2011 at 2:01 PM, David Levin <levin@chromium.org> wrote:
>
>
> On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard <glenn@zewt.org> wrote:
>>
>> On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell <kbr@google.com> wrote:
>> > On Thu, Jun 2, 2011 at 12:53 PM, David Levin <levin@chromium.org> wrote:
>> > The desire would be for this change to apply not just to the
>> > postMessage method on MessagePort and Worker but also to that on
>> > Window.
>>
>> I agree--the postMessage interfaces shouldn't drift apart more than
>> necessary.  Adding another argument to window.postMessage would be
>> unfortunate, though: that brings it up to four, which is hitting the
>> limit of a sane, rememberable API.
>>
>> Alternatively--and this has come up repeatedly of late--allow the
>> final argument to be an object.  If it's an object, it looks like
>> this:
>>
>> port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
>> [port]});
>>
>> where "transfer" and "port" are both optional.  If it's an array, it
>> behaves as it does now.
>>
>> This also allows preserving MessagePort error checking: you can still
>> throw INVALID_STATE_ERR if something other than a MessagePort is
>> included in ports.
>
>
> It feels like this array of objects given to transfer may complicate (and
> slow down) both the implementation of this as well as the developer's use of
> it.

How so? You basically use the normal API, but if there are any objects
which you'd like to have transfer the ownership of, you additionally
list them in the second argument.

There are two properties of this approach that I like:

1. It means that objects which you'd like to transfer ownership are
not "second class citizens" and can live as part of the normal object
graph that is posted, together with metadata that goes with it (or
even as metadata for other things).

2. The receiving side doesn't need to worry about the difference, all
it gets is the graph of objects that was sent to it.

> It also raises questions when I see it. When I list an object there does it
> imply that all children are also transfered or do I have to list each of
> them explicitly as well?)

None of the objects which allow transferring of ownership has children
so this doesn't appear to be a problem at this time. If it indeed does
turn into a problem, it would seem like a problem no matter what
solution is used, no?

> Then I wonder what is the use case for this complexity.
> Why not something simpler like this?
>     port.postMessage({frameBuffer: frame}, {transfer: true, ports: [port]});
> where you can just say indicate that you want the message transfered.

This means that you have to choose between transferring all arrays and
transferring none of them. It also makes it much less explicit which
objects ends up being mutated.

/ Jonas

Received on Thursday, 2 June 2011 23:24:58 UTC