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 2, 2011 at 12:58 PM, 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 interpreted (on only a quick reading) his proposal as saying that
the second list is a set of objects which, if included in the first
list, will be transferred rather than cloned.  I'd agree that it
doesn't make sense to have a separate, isolated list to transfer;
that's cumbersome.

I assume the proposal was a bit different than I read it, since that's
not how MessagePorts work.  I'd imagine it wouldn't be hard for the
list to do both: filter all objects that aren't MessagePorts, use that
set to flag transfers, and the remaining MessagePorts act as they do
now.  Sort of ugly, though.

> 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 } )?

It should be possible to request transfer ownership of some objects in
the tree and not others.  Otherwise, adding this feature to other
objects later won't be backwards-compatible, since a tree may contain
transferrable and non-transferrable objects.

-- 
Glenn Maynard

Received on Thursday, 2 June 2011 17:24:54 UTC