- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 22 Jun 2011 11:10:39 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: David Levin <levin@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, Andrew Wilson <atwilson@google.com>, Arthur Barstow <art.barstow@nokia.com>, Dmitry Lomov <dslomov@google.com>, ben turner <bent.mozilla@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Travis Leithead <Travis.Leithead@microsoft.com>
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Jun 22, 2011 at 1:57 AM, David Levin <levin@chromium.org> wrote:
>>
>> Let's say the call doesn't throw when given a type B that isn't
>> transferrable.
>> Let's also say some later changes the javascript code and uses B after the
>> postMessage call.
>> Everything work. No throw is done and B isn't "gutted" because it isn't
>> transferrable.
>
> Throwing for unsupported objects will break common, reasonable uses, making
> everyone jump hoops to use transfer. Not throwing will only break code that
> seriously misuses the API, by listing objects for transfer and then
> continuing to use the object.
>
> Anyway, if this exception is thrown, everyone's going to use a helper like
> this:
>
> function filterTransferrable(list) {
> var ret = [];
> for(var i = 0; i < list.length; ++i) {
> if(list[i] instanceof Transferrable)
> ret.push(list[i]);
> }
> return ret;
> }
>
> postMessage([A, B], filterTransferrable([A, B]));
>
> ... which will trigger the case you describe anyway.
The structured cloning algorithm itself will throw an exception if it
encounters an object type it doesn't know how to handle, in particular
a host object. See
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#safe-passing-of-structured-data
. As browsers evolve, it will be host object types that are promoted
to transferable status. Therefore, applications that are written for
browser version N+1 which supports transferring host object type Foo
will throw an exception on browser version N when sending a Foo via
postMessage simply because of its presence in the object graph,
regardless of its presence in the transfer array.
For this reason, and because I also prefer fail-fast APIs, I agree
that unsupported objects in the transfer array should raise an
exception.
I doubt that authors will write a filter for the transferable array as
you suggest, since filtering of the object graph would be necessary
too. Rather, I think that applications will be written for browsers
that support transferring host objects of a particular type.
The current proposal sounds good to me.
-Ken
Received on Wednesday, 22 June 2011 18:11:13 UTC