On Jul 3, 2014, at 10:17 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > So most of Fetch is asynchronous. If it's invoked with the synchronous > flag set it's just that it waits for the entire response before > returning. That's why I'd like to use the asynchronous path of reading > a blob. But I'd like that not to be observably different from using > the synchronous path of reading a blob. That seems wrong. OK, this is fixable. I’ll ensure that the read operation’s synchronous component does return the results thus far, but that FIleReaderSync itself ignores them in case of a midstream error, unless we collectively agree that it SHOULD return partial instead of “all or nothing” as an API. My understanding of the FileReaderSync requirement is all or nothing, but I’m open to being wrong via bug filing. Are you agreed (as far as it is possible for you to agree with me on anything) that the event loop async read might allow us to address cases like JPEG progression? It seems imminently usable here. — A*
Received on Thursday, 3 July 2014 14:29:40 UTC