Re: [File API] About Partial Blob Data, XHR and Streams API

Hi Arun,

Le 22/01/2013 15:04, Arun Ranganathan a écrit :
> Hi Cyril,
>
>
> 1) I'm wondering why in progressive mode, does the spec say: 
> |"|partial Blob data is an |ArrayBuffer|[TypedArrays 
> <http://dev.w3.org/2006/webapi/FileAPI/#TypedArrays>] object 
> consisting of the bytes|loaded|so far". Why isn't it the bytes loaded 
> since the previous progress event?
>
> AR: It is always a new ArrayBuffer.  The phraseology "so far" could be 
> replaced by "bytes loaded since the previous progress event" though 
> I'm not always sure that will be the case.
I understood from Jonas' answer that it was a new ArrayBuffer. What 
remained unclear was the content of the ArrayBuffer: all the data from 
the beginning of the read operation (which was problematic), or only the 
data read since the previous progress event (which I prefer). If, as you 
say, this is latter option, then please fix the spec. as "so far" is 
very ambiguous.

>
>     In my use case, the binary data resource might have an infinite
>     size, in which case the result objects will grow forever.
>     I looked at the Streams API [1] to see if there was any difference
>     for that but I couldn't see any. Reading with the FileReader
>     interface a Stream (dynamic length) or a Blob (fixed length) seems
>     to always return the whole content.
>
>
> AR: Here, do you mean, you never get a progressevent other than load 
> and loadend in your tests?
No, I meant that the Streams API uses the same approach as the File API:
"This method should mimic|FileReader.readAsArrayBuffer()| 
<http://dev.w3.org/2006/webapi/FileAPI/#readAsArrayBufferSyncSection>"
So, I understood reading "so far" that you would get the content of the 
stream read so far from the beginning at each time, which is practically 
unusable. If the FileAPI spec is fixed, the Streams API is fixed as well.

> Certainly, if you had binary data of infinite size, you'll get .... 
> several.... result objects.  The file API, particularly FileReader, 
> shouldn't be used in streaming scenarios.
I disagree. The File API combined with XHR should be fine for reading 
(large) files for which the size is known when making the request but 
still delivered using HTTP streaming approaches. The Streams API and XHR 
should be fine for the same thing but for (infinite) files for which you 
don't know the size (chunked transfer to simulate IceCast/ShoutCast). A 
possible problem is when the apps want to receive the exact chunks 
created by the server (point 2 in my previous email) which the 
FileReader API doesn't preserve.

Cyril

-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.wp.mines-telecom.fr/