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

Re: File API: reading a Blob

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 3 Jul 2014 16:50:27 +0200
Message-ID: <CADnb78hR5Vkf-MXwBQfn0Y1zKbWEPTT93-r-f4KJ15CHOZWewA@mail.gmail.com>
To: Arun Ranganathan <arun@mozilla.com>
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On Thu, Jul 3, 2014 at 4:29 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> 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.

That would mean you would get different results between using
FileReaderSync and XMLHttpRequest. That does not seem ideal.

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

The tasks are still a bit of a concern as a normal implementation
would not queue tasks. E.g. it's not even clear what task loop Fetch
would retrieve this from as fetch is itself a different process.

Received on Thursday, 3 July 2014 14:51:08 UTC

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