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: Ian Hickson <ian@hixie.ch>
Date: Thu, 2 Jun 2011 18:54:50 +0000 (UTC)
To: ben turner <bent.mozilla@gmail.com>, Jonas Sicking <jonas@sicking.cc>
cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1106021853310.26539@ps20323.dreamhostps.com>
On Thu, 2 Jun 2011, ben turner wrote:
> I interpreted the proposal differently... This is what I envisioned:
>   var bufferToTransfer = /* make ArrayBuffer */;
>   var bufferToCopy = /* make ArrayBuffer */;
>   var worker = /* make Worker */;
>   var message = { buf1: bufferToTransfer, buf2: bufferToCopy };
>   worker.postMessage(message, [bufferToTransfer]);
> We'd keep the structure exactly the same, it's just that when we clone 
> 'message' we compare each object value to one of the ones passed in the 
> transfer array. If the objects match (===) then we'd transfer it rather 
> than copy it.
> Does that sound like what you were hoping for?

That's fine except for breaking compatibility with the current MessagePort 
model, which is a pretty big problem.

On Thu, 2 Jun 2011, Jonas Sicking wrote:
> I also don't understand the reason for the requirement to have the type 
> participate in some specific inheritance chain. All that seems needed to 
> me is to enumerate the types which can be transferred rather than copied 
> as obviously transferring normal JS arrays or JS objects is unlikely to 
> be possible in todays JS implementations.

The idea here was just to have WebIDL do the type-checking instead of me. 
The behaviour is black-box indistinguishable.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 2 June 2011 18:55:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC