- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 3 Jun 2011 13:02:58 -0700
- To: Kenneth Russell <kbr@google.com>
- Cc: Glenn Maynard <glenn@zewt.org>, Dmitry Lomov <dslomov@google.com>, David Levin <levin@chromium.org>, ben turner <bent.mozilla@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>, Travis Leithead <Travis.Leithead@microsoft.com>
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell <kbr@google.com> wrote:
> On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard <glenn@zewt.org> wrote:
>> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov <dslomov@google.com> wrote:
>>> a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
>>> to appear in transfer lists. ArrayBuffers that are under objects in
>>> transfer lists are transferred, others are cloned.
>>
>> This again causes the same forwards-compatibility problem. If you do this:
>>
>> frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
>> postMessage({ frame: frame }, { transfer: frame });
>>
>> and you expect only histogram to be transferred (since that's all that
>> supports it when you write this code), your code breaks when
>> CanvasPixelArray later supports it.
>>
>>> b) Transfer lists + separate transferMessage method. We still equip
>>> postMessage with transfer lists, these transfer lists list ArrayBuffers, and
>>> we provide a separate method transferMessage with recursive transfer
>>> semantics.
>>> What do people think?
>>
>> Same problem.
>>
>> If you want a quicker way to transfer all messages of given types, see
>> my previous mail: { transfer: ArrayBuffer }.
>
> Agreed on these points. Using an object graph for the transfer list
> (which is what the recursive transfer list idea boils down to) also
> sounds overly complicated.
>
> May I suggest to reconsider adding another optional array argument to
> postMessage for the transfer list, rather than using an object with
> special properties?
>
> Points in favor of adding another optional array argument:
>
> 1. Less typing, and less possibility that a typo will cause incorrect behavior:
> worker.postMessage(objectGraph, null, [ arrayBuffer1ToTransfer,
> arrayBuffer2ToTransfer ]);
> vs.
> worker.postMessage(objectGraph, { transfer: [
> arrayBuffer1ToTransfer, arrayBuffer2ToTransfer] });
>
> 2. Possibility of using Web IDL to specify the type of the optional
> array argument (i.e., "Transferable[]?"). Would be harder to do using
> an object -- requiring either specifying another interface type with
> the "ports" and "transfer" attributes, or using "any" plus
> ECMAScript-specific text.
>
> Points in favor of using an object:
>
> 1. Could potentially overload the meaning of the optional ports array
> argument, avoiding adding another argument to postMessage.
>
> 2. More extensible in the future.
>
> Thoughts?
My first thought is that so far no implementer has stepped up and said
that changing the meaning of the 'ports' argument would not be
acceptable. Would be great if someone who is reading this thread and
who works at Google/Apple/Opera could check with the relevant people
to see if such a change would be possible.
/ Jonas
Received on Friday, 3 June 2011 20:03:56 UTC