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

On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan
<aranganathan@mozilla.com> wrote:
> Ken,
>
>> 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?
>
>
> Specifically, you think this is not something ArrayBuffer should inherit?  If it's also a bad idea for MessagePort, then those are really our only two use cases of Transferable right now.  I'm happy to create something like a close() on Blob.

MessagePort already defines a close() operation, so there's really no
question of whether its presence is a good or bad idea there. A
close() operation seems necessary in networking style APIs.

I would be hesitant to impose a close() method on all future
Transferable types. I don't think adding one to ArrayBuffer would be a
bad idea but I think that ideally it wouldn't be necessary. On memory
constrained devices, it would still be more efficient to re-use large
ArrayBuffers rather than close them and allocate new ones.


On Tue, Mar 6, 2012 at 1:34 PM, Michael Nordman <michaeln@google.com> wrote:
> Sounds like there's a good case for an explicit blob.close() method
> independent of 'transferable'. 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.

This sounds like a good idea. As you pointed out offline, a key
difference between Blobs and ArrayBuffers is that Blobs are always
immutable. It isn't necessary to define Transferable semantics for
Blobs in order to post them efficiently, but it was essential for
ArrayBuffers.

-Ken

Received on Tuesday, 6 March 2012 22:25:30 UTC