- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 16 Dec 2013 11:37:59 -0600
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WebApps WG <public-webapps@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
- Message-ID: <CABirCh-yr9=HBxdLp4KoM5AN1yagCwEsNU_eqRnaN=iMTrHAAg@mail.gmail.com>
On Mon, Dec 16, 2013 at 10:16 AM, Anne van Kesteren <annevk@annevk.nl>wrote: > On Mon, Dec 16, 2013 at 4:07 PM, Glenn Maynard <glenn@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
Received on Monday, 16 December 2013 17:38:26 UTC