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

On Thu, Jun 2, 2011 at 5:01 PM, David Levin <levin@chromium.org> wrote:
> 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.

Even with thousands of objects, creating an array containing them is
quick (and only needs to be done once), and the implementation would
presumably convert it to a set internally for quick lookups.  I doubt
most use cases will transfer so many separate objects, though.

(And Ian keeps drilling into our head that implementation complexity
isn't a major concern, though I don't imagine converting a list of
objects to a hash table is complex.)

In the typical cases, this seems both simple for users and fast.

> 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?)

Objects with children wouldn't support transfer--you don't transfer a
Javascript array or a basic Object this way.

Note that ImageData's ImagePixelData isn't a "child" as far as
structured clone is concerned; only Array and Object are cloned
recursively.  If ImageData gains support for transfer, then you
wouldn't include the ImagePixelData in the list; only the ImageData
itself.  (DATA_CLONE_ERR should probably be thrown if an item is
marked for transfer that isn't supported by structured clone, to make
errors related to this more obvious.)

> 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.

Adding transfer support to more types in the future would become
backwards-incompatible.

-- 
Glenn Maynard

Received on Thursday, 2 June 2011 21:31:06 UTC