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.
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?)
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.
dave
Received on Thursday, 2 June 2011 21:01:55 UTC