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

(It would have been better not to fork the thread with a different
subject line...)

On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
<Travis.Leithead@microsoft.com> wrote:
> I'm a little concerned about the inherit approach that Ian outlines...
>
> This plan requires all objects that want to opt-in to a new transfer-of-ownership (or really any special custom behavior for postMessage) to 1) participate in the special inheritance interface and 2) be isolated from the primary object graph being passed to the first parameter. For example, instead of allowing the structured clone algorithm to preserve all my object relationships as-is, I will have to detach some objects from the graph (to include in the proposed 2nd parameter to postMessage) and then re-attach them on the destination side.

I realize I misunderstood the proposal. I thought the additional array
of objects was supposed to indicate those in the object graph that
wanted ownership to be transferred. Having to send these objects
separately from the rest of those in the graph is undesirable and in
my opinion unworkable.

> Isn't there some way we can flag the objects that want transfer of ownership by a property or identifier on the objects themselves? That way, they won't have to be special-cased into a separate list. For example, if the ArrayBuffer added a property indicating transfer-of-ownership? Or a new configuration option for postMessage ( { transferOwnership: true } )?

A per-object property is undesirable because it forces all types that
want to participate in transfer of ownership to add a new property
specifically for the Web Messaging spec.

I still like the idea of identifying those objects in the graph passed
to postMessage which should be transferred rather than copied, since
it's flexible and should be easy to use. (Though maybe not, if the
object graph is deep and it's difficult to pull out all the objects
you want to transfer?) Adding a flag to postMessage, or adding a new
entry point like transferMessage, also seem fine.

-Ken

> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@nokia.com]
> Sent: Thursday, June 02, 2011 9:02 AM
> To: ext Jonas Sicking; Kenneth Russell; Ian Hickson
> Cc: Travis Leithead; gman@google.com; cmarrin@apple.com; glenn@zewt.org; public-webapps@w3.org
> Subject: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
>
> What are the specific change(s) to the Web Messaging spec being proposed:
>
>   http://dev.w3.org/html5/postmsg/
>
> -AB
>
> On Jun/2/2011 11:25 AM, ext Jonas Sicking wrote:
>> On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell<kbr@google.com>  wrote:
>>> On Tue, May 31, 2011 at 3:35 PM, Ian Hickson<ian@hixie.ch>  wrote:
>>>> On Tue, 31 May 2011, Kenneth Russell wrote:
>>>>> Jonas's suggestion of adding another argument to postMessage, and
>>>>> Gregg's generalization to declare it as an array of objects to be
>>>>> transferred rather than copied, sounds good.
>>>> We could change make MessagePort and ArrayBuffer both inherit from a
>>>> [NoInterfaceObject] empty interface, and then make the MessagePort[]
>>>> argument of the various postMessage() methods instead take an array
>>>> of this new interface, and then just have ArrayBuffer and
>>>> MessagePort both define how to be cloned in this way.
>>>>
>>>> If people like this approach I can work with Kenneth on getting the
>>>> wording right in the various specs.
>>> This sounds good to me; in the interest of moving things forward, are
>>> there any objections?
>> No, this sounded good to the people here at mozilla that I talked with
>> about this.
>>
>> / Jonas
>>
>
>

Received on Thursday, 2 June 2011 17:21:40 UTC