[Bug 25242] Blob.close should not set the blob's size to 0 or cause slice() to throw

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25242

Jonas Sicking <jonas@sicking.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonas@sicking.cc

--- Comment #1 from Jonas Sicking <jonas@sicking.cc> ---
I don't think we'll ever be able to cause all slices to be closed. For example,
if a Blob is backed by a file, and you postMessage a slice of that Blob to
another thread/process it seems hard to make sure any reads from the slice
fail. It would mean that any attempts to read from the blob couldn't just be
implemented by opening the file and reading form it. Instead you have to proxy
a message to the thread which the blob was originally sliced from and see if
the blob has been closed. This might involve bouncing to multiple threads since
you can create slices from slices. This seems terrible performance-wise.

Also, why are you specifically calling out slices? What about things like
|x = new Blob([myblob]); myblob.close();|? Would that also cause x to get
closed? If not, wouldn't you be stuck with the same problem as you have with
slices?

So I don't think we should change behavior of .close() for that reason.


That said, I wouldn't mind changing Blob.close() such that it causes fewer
other operations to fail.

Making calling Blob.slice() on a closed blob not throw and instead return a
closed Blob seems fine and creates fewer exceptional cases which is good.

I don't really feel strongly about if the size should be set to 0. It does seem
good to have a way to indicate that a blob is actually closed. You shouldn't
need to attempt to read from it and see if you get an error back. However
setting the size to 0 isn't a great way to do that since you still can't tell a
closed blob from one that is truly empty.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 3 April 2014 06:58:51 UTC