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

Re: Streams and Blobs

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 28 Feb 2013 11:44:44 +0000
Message-ID: <CADnb78gt1EHzu8wfChfQMmQo7DBgOiP6hWFvkizXf4QY+5Zpww@mail.gmail.com>
To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Cc: public-webapps@w3.org
On Wed, Feb 27, 2013 at 10:03 PM, Cyril Concolato
<cyril.concolato@telecom-paristech.fr> wrote:
> I was confused when reading only:
> "The arraybuffer response entity body is an ArrayBuffer representing the
> response entity body."
> and then:
> "The response entity body is the fragment of the entity body of the response
> received so far (LOADING) or the complete entity body 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.

It cannot be in one place because you have to return the same object.
So you need some place where you create that object and then keep
returning it from there.


> 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.

Note that you get the same Blob if nothing changed.


> 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?

moz-chunked-text goes via .response too, but I'm not sure that's worth
having given the majority case seems ArrayBuffer and we have
TextDecoder in case that's not sufficient.


-- 
http://annevankesteren.nl/
Received on Thursday, 28 February 2013 11:45:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT