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, 10 Jul 2014 13:05:13 -0400
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Kyle Huey <me@kylehuey.com>
Message-Id: <42300A80-A347-42AC-9B2D-93B109A2D75F@mozilla.com>
To: Anne van Kesteren <annevk@annevk.nl>
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

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