Re: File API: reading a Blob

On Jul 3, 2014, at 10:50 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> 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



The implementation train has already left the station on this. The movitation of an “ideal" match-up with XMLHttpRequest doesn’t seem strong enough to revisit this by filing browser bugs across implementations (but Cc’ing K. Huey also).

We agreed some time ago to not have partial data.


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


Then let’s have a different read operation that doesn’t use the FileReader Task Source. The primary API in File API uses the event loop (FileReader), so for that purpose, the existing read operation is important. Early discussions about this made me feel that a task queue based system to asynchronously read blobs could be reusable by Fetch, and by future Promise-based APIs. 

Since it’s not reusable for Fetch, let’s not try and force it. We’ll do a new one along the lines you described at the start of this email.

— A*

Received on Thursday, 10 July 2014 17:05:45 UTC