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, 31 Jul 2014 12:30:13 -0700
Cc: Anne van Kesteren <annevk@annevk.nl>, Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Kyle Huey <me@kylehuey.com>
Message-Id: <19E00493-4B42-4C93-BBD2-F9692A11EE0D@mozilla.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Aymeric,

(Sorry for the delay; I was traveling for the last part of July.) 

On Jul 17, 2014, at 11:25 AM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:

> I don't get this, most reads inside browsers are about fetching, and fetching does increment a resource while it is loaded/displayed (image, video, crypto operations, etc)
> 
> And it's question of the fetch API in this thread.
> 
> XHR has the same issue, fortunately you can use XHR with Range, now I think this issue should stop propagating


What I meant is that while I donít think FileReader *or* FileReaderSync should be modified *at this stage* to include partial data, there is a workaround:

1. After obtaining the Blob or File, use .slice() to generate something like a mySlices[ ] array of e.g. 2K each slice.

2. Then use fileReader.readAsArrayBuffer(mySlices[0]Ö). 

This should be relatively efficient, and in fact can be cued to work at the completion of the last read, based on the final event being fired (or something similar ó you get the idea). This might be similar to XHR range.

This at least allows chunked reads. I agree that we need a stream-based API, but I donít agree that it should be FileReader or FileReaderSync. Thatís simply doing too much with too little. However, I think the next step would be to generate stream-based reads directly off the Blob, e.g. have something like myBlob.read(Ö) which returns a stream, which can be cued with API calls.


> 1. Decoding was an issue with *readAsText*. I suppose we could make that method alone be all or nothing.
> I don't see where the issue can be, it should behave like textdecoder and reinject the undecoded bytes to the next chunk, personnaly I find really useless to offer the 'text' methods in files/fetching APIs.


The issue is that it isnít possible to know the total number of decoded bytes is till the whole file is decoded, but of course we could only represent the bytes read thus far in progress events. Again, I donít think FileReader or FileReaderSync are the right APIs for that.  

ó A*
Received on Thursday, 31 July 2014 19:31:25 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:16 UTC