W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: File API: reading a Blob

From: Arun Ranganathan <arun@mozilla.com>
Date: Thu, 3 Jul 2014 10:29:08 -0400
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
Message-Id: <F7D45098-2ECB-41CD-95F4-76B105CA3DA8@mozilla.com>
To: Anne van Kesteren <annevk@annevk.nl>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC