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

On Wed, Jun 8, 2011 at 2:39 PM, David Levin <levin@chromium.org> wrote:
>
>
> On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> I prefer continuing to use an array for several reasons: simpler
>> syntax, better type checking at the Web IDL level, and fewer
>> ECMAScript-specific semantics.
>
> An array makes it harder to do future modifications.

Possibly, but it makes the design of this modification cleaner.

> Also with the array, how does "Enhance the ability to pass MessagePorts, so
> that the object graph can refer to them as well" work? Specifically,
> consider an array that contains [arrayBuffer1, port1]. Is port1 something in
> the object graph or a port to be transfer as before?

In order to maintain backward compatibility, the clone of port1 would
show up in the "ports" attribute of the MessageEvent on the other
side. Additionally, during the structured clone of the object graph,
any references to port1 would be updated to point to the clone of
port1. (The latter is new behavior, and brings MessagePorts in line
with the desired transfer-of-ownership semantics.)

All other objects in the array (which, as Ian originally proposed,
would implement some interface like "Transferable" for better Web IDL
type checking) would simply indicate objects in the graph to be
transferred rather than copied.

Note: it would still be possible to evolve the API to transfer all
objects of a certain type. We would just need to change the type of
the "ports" or "transfer" array from Transferable[] to any[] and spec
what happens when a constructor function is placed in the array.

-Ken

> dave
>
>>
>> -Ken
>>
>> On Wed, Jun 8, 2011 at 2:29 PM, David Levin <levin@chromium.org> wrote:
>> >
>> >
>> > On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell <kbr@google.com> wrote:
>> >>
>> >> My understanding is that we have reached a proposal which respecifies
>> >> the "ports" argument to postMessage as an array of objects to
>> >> transfer, in such a way that we:
>> >
>> > Array or object? (by object I mean: {transfer: [arrayBuffer1], ports:
>> > [port]})
>> >
>> >>
>> >>  - Maintain 100% backward compatibility
>> >>  - Enhance the ability to pass MessagePorts, so that the object graph
>> >> can refer to them as well
>> >>  - Allow more object types to participate in transfer of ownership in
>> >> the
>> >> future
>> >>
>> >> To the best of my knowledge there are no active points of
>> >> disagreement. I think we are only waiting for general consensus from
>> >> all interested parties that this is the desired step to take.
>> >>
>> >> If it is, I would be happy to draft proposed edits to the associated
>> >> specs; there are several, and the edits may be somewhat involved. I'd
>> >> also be happy to share the work with Ian or anyone else.
>> >>
>> >> I don't know the various processes for web specs, but the Web
>> >> Messaging spec will definitely need to be updated if we decide to move
>> >> in this direction.
>> >>
>> >> -Ken
>> >>
>> >> On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow <art.barstow@nokia.com>
>> >> wrote:
>> >> > Now that the responses on this thread have slowed, I would appreciate
>> >> > if
>> >> > the
>> >> > participants would please summarize where they think we are on this
>> >> > issue,
>> >> > e.g. the points of agreement and disagreement, how to move forward,
>> >> > etc.
>> >> >
>> >> > Also, coming back to the question in the subject (and I apologize if
>> >> > my
>> >> > premature subject change caused any confusion or problems), since we
>> >> > have an
>> >> > open CfC (ends June 9 [1]) to publish a Candidate Recommendation of
>> >> > Web
>> >> > Messaging, is the Messaging spec going to need to change to address
>> >> > the
>> >> > issues raised in this thread?
>> >> >
>> >> > -Art Barstow
>> >> >
>> >> > [1]
>> >> >
>> >> > http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
>> >> >
>> >
>
>

Received on Wednesday, 8 June 2011 23:27:38 UTC