No, they're the same thing: a structured clone of a neutered Blob should throw DataCloneError, and the overall effect should be the same (making the object permanently inaccessible).

(It looks like actually making neutered Blobs throw during structured clone was forgotton, though.  I think I assumed this was done for all objects and didn't need special handling.  I'll file a separate bug.)

Hixie disagreed. That was bug 23385.

And I think I agree with Ian. Transfering and neutering are tied.

This matters even more once https://github.com/dslomov-chromium/ecmascript-structured-clone makes its way into JavaScript as you wouldn't want to annotate a non-transferable with [[Transfer]].

Why exactly?

Do you mean:

1. Coin a new method that is the equivalent of Blob.close() (say, hypothetically, Blob.shut())?

Or

2. Do you mean conceptually separate Blob.close() from structured clones in the prose?

The method name is intuitive, and the behavior is *almost* identical; the concept in HTML is analogous enough to borrow directly from.

2 and as I outlined in comment 2 it is not. Ask Hixie if you need more background.

"Ask someone else for more info" isn't really a reasonable response, when you're the one that opened the bug.

FYI, I already filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23417.  Otherwise, I'd reopen 23385, which was closed without explanation to people reading the bug.

If transferring a neutered Blob doesn't throw an exception, and results in a neutered Blob on the other side, then transferring a neutered ArrayBuffer needs to also not throw an exception and result in a neutered ArrayBuffer on the other side.  The effect of Blob.close() making the Blob inaccessible is logically equivalent to transfer making objects inaccessible.  It's strange and inconsistent for them to have different sets of side-effects.  Dead objects should either be clonable or not, whether they're an ArrayBuffer or a Blob.

Pulling out Blob.close() into a separate thing that's just like neutered but separate is the worst solution.

You can't transfer a Blob. It's not Transferable. It doesn't need to be (it has no mutable state that can't be shared). The concept of "neutering" for the purposes of Tranferable objects doesn't apply to things that aren't Transferable.

There's no difficulty here. You just define your own prose term like "neutered blob" and use that.

There's nothing specific to Transferable about the effects of neutering.  Closed blobs want the exact same behavior--throwing an exception when the object is accessed or structured cloned--so it should use the same concept, not introduce a new concept that does the same thing.

I agree with Glenn. No inconsistencies in the APIs, please.
Either you can transfer an object (and neuter it on the original side) or you cannot.

I do think that Blob should be a Transferable, and close() should be a Transferable method, since the user-visible behavior of transfer and the immediate-release of .close() are the same: the object is no longer accessible.  However, that's a separate issue, and my argument here is narrower: the concept of "this object is dead and inaccessible", aka neutering, should be the same for both transfer and Blob.close() with identical effects (eg. throwing exceptions on access and structured clone), and transfer is simply one user of the neutering concept.

(Just clarifying a bit, so we don't tangent into the "should Blobs be Transferable" discussion, which is related but orthogonal to this.)

The concept of "neutered" in the Transferable sense is "this can't be transferred any more". Anything that isn't Transferable is always in that state, so it doesn't make sense to talk about other things being neutered in the Transferable sense.

If File and Blob should be Transferable (meaning they can't be cloned, or that cloning them is an expensive operation), then that's a different matter. My understanding is that that is not the case currently.


I really don't understand the problem here. It's fine to be able to send the object into a different state. Lots of objects do this. WebSocket objects can get closed. Windows can get closed. XMLHttpRequest objects can go into several states. And so on.

(In reply to Ian 'Hixie' Hickson from comment #11)
> The concept of "neutered" in the Transferable sense is "this can't be
> transferred any more". Anything that isn't Transferable is always in that
> state, so it doesn't make sense to talk about other things being neutered in
> the Transferable sense.
> 
> If File and Blob should be Transferable (meaning they can't be cloned, or
> that cloning them is an expensive operation), then that's a different
> matter. My understanding is that that is not the case currently.
> 
> 
> I really don't understand the problem here. It's fine to be able to send the
> object into a different state. Lots of objects do this. WebSocket objects
> can get closed. Windows can get closed. XMLHttpRequest objects can go into
> several states. And so on.

Blobs aren't going to be Transferable -- they don't need to be.

You're right: it isn't a big deal to roll a new one. 
http://dev.w3.org/2006/webapi/FileAPI/#dfn-close

Marking this fixed.

Checked in as WHATWG revision r8279.
Check-in comment: Update terminology to match File API spec
http://html5.org/tools/web-apps-tracker?from=8278&to=8279