Re: Adding fields for transfer map to Intent constructor

On 3/12/2012 1:43 PM, Greg Billock wrote:
> On Mon, Mar 12, 2012 at 1:39 PM, Paul Kinlan<paulkinlan@google.com>  wrote:
>> So does this mean that .ports will be populated by iterating through
>> the transferable array and looking to see if it is a MessagePort or
>> not?
> Internally it's more intricate than that, but from the javascript
> side, yes, it looks like the machinery is looking through the transfer
> map argument, pulling out the ports, and putting them into 'ports'.

We have to maintain the fallback semantic for Transferable objects. Paul 
would like it obsoleted.

>> Sorry if this seems dense, but if we are passing the ports in data
>> (and transferable array), then we should access it on intent.data and
>> thus remove any need for .ports
> Agreed, but I don't think that's how structured clone and
> transferables work currently. Charles may have more info on the
> current and imagined behavior.

Paul, consider the basic array buffer transfer. This is the simplest, 
raw protocol of web messaging.
Sending side:
postMessage(buffer, [buffer]);
https://www.khronos.org/registry/typedarray/specs/latest/#9

That's saying, here is a block of binary data, you have it, I don't need it.
If transfer is working, that block of data can be transferred between 
threads without running a memory copy.
When it's not working, it does a normal memory copy even when it's 
between threads.

You can use this method to transfer binary over window.name and other 
challenging polyfill paths.

On the receiving side, the author runs a very simple accessor.
var data = message.ports[0] || message.data;

Received on Monday, 12 March 2012 20:54:44 UTC