Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 3:18 PM, Kenneth Russell <kbr@google.com> wrote:
> A change like this would be feasible as long as it doesn't break
> compatibility. In other words, the current Transferable array would
> still need to be supported, but Transferable instances (or perhaps
> instances of some other type) wrapping another Transferable object
> would also express the intent.

I don't like this, because it loses the invariant that structured clone is
a const operation by default.  That is, if you don't explicitly specify
objects in the transfer map, structured clone guarantees that the object
you pass in won't be modified, and that (as a corollary) you can create as
many structured clones as you want.  This always works:

function(obj)
{
    thread1.postMessage(obj);
    thread2.postMessage(obj);
    thread3.postMessage(obj);
}

With the "wrapper" approach, it would no longer be guaranteed to work.

I'm not sure that adding close() to Transferable is a good idea. Not
> all Transferable types may want to support that explicit operation.
> What about adding close() to Blob, and having the neutering operation
> on Blob be defined to call close() on it?
>

When would you explicitly want to disallow manually neutering a
Transferable object?

The only case I can think where it's not obviously useful is MessagePort,
but I think that will be an exceptional case and that most Transferables
will want this method.  ArrayBuffer (currently the only other Transferable)
will, of course.

On Tue, Mar 6, 2012 at 3:34 PM, Michael Nordman <michaeln@google.com>
 wrote:
>
> Separately defining blobs to be transferrable feels like an unneeded
> complexity. A caller wishing to
> neuter after sending can explicit call .close() rather than relying on
> more obscure artifacts of having also put the 'blob' in a
> 'transferrable' array.
>

You can always call close() yourself, but Blob.close() should use the
"neuter" mechanism already there, not make up a new one.

-- 
Glenn Maynard