[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

--- Comment #2 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Jonas Sicking from comment #1)
> 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.

I think my mental image of what would happen was based on a view of the
top-level blob.  That part's easy, since the closed state can be written to the
file on disk as metadata; other threads can just look at that, and not
communicate directly.  But, that doesn't work when closing slices, since you'd
only want to close that slice and its sub-slices, not the "parent" blob.  (This
could probably be done with nested blobs, but it'd be a lot more complex and
much more like IPC.)

> 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?

That's probably an issue, too.  But the "close all sub-blobs" solution may not
make sense there, since unlike slicing, nested blobs don't have a tree
structure.  It's not so obvious whether closing the containing blob should
close the inner one.  So, maybe the solution is something else.

> 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.

Exposing a separate Blob.closed property would be better than making it appear
as though the Blob's data was mutable, I think.

One simple example: a site displays "Processed: 450/5000 bytes", updating as it
processes the file: refresh() { processed.innerText = totalCompleted + "/" +
blob.size; }.  If the user cancels, it closes the blob, stops the operation and
refreshes one more time, which causes it to say "Processed: 450/0 bytes".  It's
just one more thing to have to work around.

(Structured clone should probably also just clone a new closed blob.  That's in
HTML, so I'll only file a bug on that if the close()-based exceptions in File
API itself go away.)

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

Received on Friday, 4 April 2014 00:22:34 UTC