23416 2013-10-02 01:19:54 +0000 Introduce new concept of neutered 2013-11-13 22:09:05 +0000 1 1 1 Unclassified WebAppsWG File API unspecified PC All RESOLVED FIXED P2 normal --- 23417 1 annevk arun arun bugs glenn ian public-webapps public-webapps-bugzilla oldest_to_newest 94136 0 annevk 2013-10-02 01:19:54 +0000 The concept of neutered you import from HTML is used for structured clones. You should introduce your own concept here as neutering a Blob is unrelated to structured clones. 94138 1 glenn 2013-10-02 01:35:50 +0000 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.) 94141 2 annevk 2013-10-02 02:59:50 +0000 Hixie disagreed. That was bug 23385. 94142 3 annevk 2013-10-02 03:05:25 +0000 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]]. 94143 4 arun 2013-10-02 03:08:34 +0000 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. 94144 5 annevk 2013-10-02 03:09:56 +0000 2 and as I outlined in comment 2 it is not. Ask Hixie if you need more background. 94145 6 glenn 2013-10-02 03:27:03 +0000 "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. 94338 7 ian 2013-10-04 21:47:39 +0000 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. 94342 8 glenn 2013-10-04 21:56:07 +0000 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. 94353 9 bugs 2013-10-04 23:23:20 +0000 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. 94360 10 glenn 2013-10-05 00:59:15 +0000 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.) 94429 11 ian 2013-10-07 22:33:28 +0000 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. 95645 12 arun 2013-10-31 22:59:07 +0000 (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. 96259 13 contributor 2013-11-13 22:09:05 +0000 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