Re: File API - Progress - Question about Partial Blob data

On Tue, Aug 20, 2013 at 4:13 PM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:
> The specs says :
>
> " It can also return partial Blob data. Partial Blob data is the part of the
> File or Blob that has been read into memory currently; when processing the
> read method readAsText, partial Blob data is a DOMString that is incremented
> as more bytes are loaded (a portion of the total) [ProgressEvents], and when
> processing readAsArrayBuffer partial Blob data is an ArrayBuffer
> [TypedArrays] object consisting of the bytes loaded so far (a portion of the
> total)[ProgressEvents]. The list below is normative for the result attribute
> and is the conformance criteria for this attribute"
>
> What is the rationale for that? The result attribute should better contain
> for progress events the latest data read and not the data read from the
> begining that you could easily reconstitute while the contrary requires more
> work.
>
> Use case: calculate the hash of a file while you are reading it.
>
> Regards
>
> Aymeric
>
> PS: I did not test it in all browsers, but unless I am using it wrongly, the
> result attribute is always null for progress events.

I agree that we need a way to read from a File/Blob such that you get
"incremental" data, i.e. that you only get the data read since the
last data deliver, rather than getting an ever increasing result
representing all data from the beginning of the File/Blob.

However I don't think FileReader is going to be that API. FileReader
was specifically designed after XMLHttpRequest, which I think in
hindsight was a bad idea. However it was the request that we got from
several authors.

I put an initial sketch of what I think the future of File/Blob
reading should look like here:
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0727.html

That proposal supports what you are asking for, though of course there
are plenty of debate needed on various aspects of that proposal.

All that said, I thought that we had tried to avoid the mistake that
XHR did of exposing ever-increasing partial results as data was being
loaded. Exposing partial data can require quadratic memory allocations
since the implementation will have to keep reallocating and copying
data.

I thought that we had decided not to expose partial results during the
loading. And instead only expose a result at the end of the load. But
I see that the spec now calls for exposing partial results in a few
cases. Did that change?

What does implementations do? Looking at Gecko's implementation I
don't think we ever expose partial results.

/ Jonas

Received on Wednesday, 21 August 2013 17:04:05 UTC