On Thu, Jun 2, 2011 at 12:58 PM, Travis Leithead
<travis.leith...@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
