W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Kenneth Russell <kbr@google.com>
Date: Thu, 2 Jun 2011 13:16:33 -0700
Message-ID: <BANLkTimCe9vNZP4D4W1v8sNCYGnVBWC5yGB1Srmoie_vzJL=xw@mail.gmail.com>
To: David Levin <levin@chromium.org>
Cc: Jonas Sicking <jonas@sicking.cc>, ben turner <bent.mozilla@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, Jun 2, 2011 at 12:53 PM, David Levin <levin@chromium.org> wrote:
> In summary, there is a desire for a mechanism to transfer objects (to allow
> for potentially better perf) across a MessagePort.
> The mechanism:
>
> needs to have an intuitive feel for developers,
> must preserve backwards compatibility,
> should ideally allow the port to function the same regardless of whether the
> message was cloned or transferred.
> should be easy to use.
>
> There are three ideas for how to accomplish this:
> 1. Mixing in the list of objects to be cloned with the ports and use that
> list to determine what objects in the message should be cloned.
>
> This allows a lot of flexibility.
> It feels odd mixing in a list of objects with the ports when the two have
> nothing related.
> It also feels complicated having to add objects in two places (the message
> and this extra array).

Another option which was mentioned:

1a) Add another optional argument to postMessage after the array of
ports, which would be an array of objects to transfer rather than
clone.

I think 1a) is the best way to expose the functionality. As Glenn
pointed out, for backward and forward compatibility reasons, it's best
if the developer explicitly selects the objects to transfer.

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.

-Ken

> 2. Adding another parameter to postMessage "clone"/"transfer" or true/false,
> etc.
>
> It is less flexible than 1.
> It is very simple and easy to use.
> It may not be as noticeable when reading the code that this postMessage does
> a transfer of items.
>
> 3. Adding another method transferMessage with the same parameters as
> postMessage.
>
> It is less flexible than 1.
> It is very simple and easy to use.
> It may be a pain to keep this in sync with postMessage.
> It should be very noticeable when reading code.
>
> What do you think is the best way to expose this to web developers?
> dave
>
>
Received on Thursday, 2 June 2011 20:16:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT