W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Streams and Blobs

From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Date: Wed, 27 Feb 2013 23:03:20 +0100
Message-ID: <512E82A8.8040500@telecom-paristech.fr>
To: Anne van Kesteren <annevk@annevk.nl>, public-webapps@w3.org
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.
>> 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 
theresponse 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 
or the completeentity body 
<http://tools.ietf.org/html/rfc2616/#section-7.2>of the response (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 
moz-chunked-arraybuffer: .response = a different arraybuffer object 
containing partial data (non-overlapping), on LOADING and DONE, null 
moz-chunked-text: .responseText = a different string object containing 
partial data (non-overlapping), on LOADING and DONE, null otherwise.
Is that correct?


Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
Received on Wednesday, 27 February 2013 22:03:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC