- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 3 Jun 2011 14:48:07 -0700
- To: Dmitry Lomov <dslomov@google.com>
- Cc: Kenneth Russell <kbr@google.com>, Glenn Maynard <glenn@zewt.org>, 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 2:25 PM, Dmitry Lomov <dslomov@google.com> wrote:
> (I am answering on multiple points - I do not want to fork the thread)
>
> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> 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.
>
> Right, but you should not write { transfer : frame }, you should write:
> postMessage( { frame: frame }, { transfer: frame.histogram })
> in this case. The guidance for transferring objects should be: do not
> transfer objects you intend to use on this "thread" (on main thread, worker)
> - only transfer parts that you do not intend to use. This version of
> postMessage gives a high-fidelity tool for you to do so if desired, but
> handles the opaque case as well.
Right, but we all know that web authors (and us too) quite often have
bugs. Web authors in particular are infamous for using things as long
as they work even if it happens to rely on undefined behavior, browser
bugs, or goes against recommendations in the spec.
The point is that if we allow whole object graphs to be transferred,
we are making it much riskier for ourselves in the future to add
additional transferable types. It does not seem unlikely at all that
we'll end up wanting to make a type transferable but are unable to do
so because a couple of big sites rely on them not to be.
>> > 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.
>
> It feels that but not solving this as part of messaging spec we just offload
> the complexity to the users.
Complexity comes in many forms and shapes. I much more like the idea
of explicit APIs that make it clear what happens and make it hard to
shoot yourself in the foot. Yes, it can involve more typing, but if it
results in more resilient code which contains fewer subtle bugs, then
I think we have designed the API well.
/ Jonas
Received on Friday, 3 June 2011 21:49:05 UTC