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.concol...@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/
