On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan <aranganat...@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 <micha...@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
