On Mon, Dec 16, 2013 at 10:16 AM, Anne van Kesteren <ann...@annevk.nl>wrote:
> On Mon, Dec 16, 2013 at 4:07 PM, Glenn Maynard <gl...@zewt.org> wrote:
> > What I meant is that it would be good for the above pattern to work, and
> not
> > cause an IO error.
>
> Can't you always get an IO error? User removes the file, some kind of
> hard drive failure, etc.
>
Sure. I mean that it shouldn't fail at all. We should enable this as a
pattern:
function doSomething(url)
{
var xhr = new XMLHttpRequest();
xhr.open("GET", url);
xhr.send();
xhr.onload = complete_request;
}
...
function foo()
{
var blob = createSomeBlob();
var url = URL.createObjectURL(blob);
doSomething(url);
URL.revokeObjectURL(url); // or use autorevoke, but this should work too
blob.close();
}
Where the author of foo() doesn't know anything about the internals of
doSomething. If this throws an IO error then it won't work, since closing
the blob will cause doSomething's request to fail. You'd have to either
add a callback mechanism so foo() can call close() later, which you
shouldn't need to do for an API that simply takes a URL.
This way, you call close() to indicate that you're done with the instance
of the blob. The browser can't actually discard the underlying data
immediately, but it knows that it can as soon as the XHR fetch finishes.
This would be undetectable from scripts and the blob would still be
unusable for the script immediately.
--
Glenn Maynard
