Re: Streams and Blobs

Hi Anne,

Le 26/02/2013 17:34, Anne van Kesteren a écrit :
> On Tue, Feb 26, 2013 at 3:01 PM, Cyril Concolato
> <cyril.concolato@telecom-paristech.fr> wrote:
>> Hi Anne,
> Did you mean to reply just to me?
No, adding the list.
>
>
>>   * moz-blob
>>
>> Is this the same as "blob" specified in the XHR2 draft [1]?
> No, it's available during LOADING.
Ok.
>
>
>> Is "moz-chunked-arraybuffer" supposed to be the same as "arraybuffer" of the
>> draft?
> No. The draft only exposes on load, which is what browsers are
> supposed to implement...
I was confused when reading only:
"Thearraybuffer response entity bodyis an|ArrayBuffer 
<http://www.khronos.org/registry/typedarray/specs/latest/#ARRAYBUFFER>|representing 
theresponse entity body 
<https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#response-entity-body>."
and then:
"Theresponse entity bodyis the fragment of theentity body 
<http://tools.ietf.org/html/rfc2616/#section-7.2>of the response 
received so far (LOADING 
<https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-loading>) 
or the completeentity body 
<http://tools.ietf.org/html/rfc2616/#section-7.2>of the response (DONE 
<https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-done>)."
It is true that step 1 in the "otherwise" statement in 4.7.8 ("if the 
state is not DONE, return") is clear. It would probably be better if the 
text was only in one place.
>
>
>> By "chunked" do you mean that a given ArrayBuffer does not contain any data
>> overlapping with the previous or following ArrayBuffer (if any) as opposed
>> to blob which gives you the concatenation of the previous Blob and the new
>> data, right?
> That is chunked yes. What you call "blob" is what I call incremental
> and does not exist in the draft.
>
>
>> Also, do you intend to have one ArrayBuffer per chunk received in HTTP1.1,
>> or will the two notions be independent (1 ArrayBuffer possibly gathering
>> data from 2 or less than 1 HTTP chunk)?
> It will depend on when you last get .response. At least that is how
> chunked works as I understand it.
>
>
>> It may be the same use case, I'm not sure what you mean by transferred vs.
>> read. One use case is to have XHR as a source of data for MediaSource. In
>> this case, you want to have independent non-concatenated buffers and pass
>> them to the MediaSource object.
> Yeah, I think that is the give me the last buffer case without any
> storing like chunked does.
>
>
Ok, I think I agree with you. In summary, we'd have:
blob: .response = full data as a Blob, on DONE, null otherwise.
arraybuffer: .response = full data, on DONE, null otherwise.
moz-blob: .response = a different blob object containing partial data 
(not overlapping with previous/next blobs), on LOADING and DONE, null 
otherwise.
moz-chunked-arraybuffer: .response = a different arraybuffer object 
containing partial data (non-overlapping), on LOADING and DONE, null 
otherwise.
moz-chunked-text: .responseText = a different string object containing 
partial data (non-overlapping), on LOADING and DONE, null otherwise.
Is that correct?

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/