- From: Kenneth Russell <kbr@google.com>
- Date: Thu, 2 Jun 2011 13:16:33 -0700
- 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 UTC