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 23, 2011 at 4:52 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 21 Jun 2011, Ian Hickson wrote:
>>
>> How about we just make postMessage() take the object to clone in the first
>> argument, an array of objects to transfer in the second; on the other
>> side, the author receives the object cloned, with anything listed in the
>> array and in the structured data being transferred instead of cloned, and,
>> in addition, in the event.ports array, a list of the ports that were given
>> in the transfer array.
>>
>> This has the advantage of being completely backwards-compatible.
>>
>> So for example, on the sending side:
>>
>>    postMessage(['copied', copiedArrayBuffer, transferredArrayBuffer,
>>                 transferredPort1], // could be an object too
>>                [transferredArrayBuffer, transferredPort1,
>>                 transferredPort2]);
>>
>> ...on the receiving side, the event has
>>
>>    data == ['copied', newCopiedArrayBuffer, newTransferredArrayBuffer,
>>             newTransferredPort1];
>>    ports == [newTransferredPort1, newTransferredPort2];
>>
>> It's not going to win any design awards, but I think that boat has sailed
>> for this particular API anyway, given the contraints we're operating under.
>
> Since no serious problems were raised with this and it seems to address
> all the constraints, I've now specced this.
>
> One edge case that wasn't mentioned above is what happens when a non-port
> Transferable object is in the second list but not the first. I defined it
> such that it still gets cloned (and thus the original is neutered), but it
> is then discarded. (That definition more or less fell out of the way one'd
> have to implement this to make it simple to understand, but I'm happy to
> do it a different way if there's a good reason to.)
>
> http://html5.org/tools/web-apps-tracker?from=6272&to=6273

Thanks, this looks great!

Minor issue: there are a few places where "transfered" should be "transferred".

Slightly larger issue. In the typed array spec, views like
Float32Array refer to an ArrayBuffer instance. It's desired to be able
to transfer multiple views of the same ArrayBuffer in the same
postMessage call. Currently, because each Transferable is transferred
independently, transferring the first view will cause the view and
underlying ArrayBuffer to be neutered, so upon encountering the second
view, an exception will be thrown since its ArrayBuffer was already
transferred.

This could happen with any Transferable object that has a reference to
another Transferable, so I don't think it's a problem overly specific
to typed arrays.

The way this was addressed in the current typed array strawman
proposals was to split the transfer operation into two stages: cloning
of, and closing of, the original object. First, all transferable
objects were cloned, and then they all were closed. See
http://www.khronos.org/registry/typedarray/specs/latest/#9.2 .

This can be addressed in the current spec by stating in
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#transferable-objects
that the transfer map is provided to the steps defined by the type of
the object in question. That way, transferring of a particular object
can update the map during the transfer operation, possibly adding more
associations to it. The map will provide enough state to allow
transfer of dependent transferable objects.

Thoughts? Should I file a bug about this?

> kbr: Feel free to ping me if you need advice on how to use this with
> ArrayBuffer in the short term. On the long term I'm happy to just spec
> this in the same spec as the rest of this stuff.

Thanks. In the long run I'd be very happy to have the semantics for
ArrayBuffer and views defined in this spec. In the short term, I'd
like to prototype this first and get some experience with it.

-Ken

Received on Friday, 24 June 2011 22:17:28 UTC