On Fri, 29 Oct 2010 07:55:58 +0200, David Flanagan
da...@davidflanagan.com wrote:
I doubt I understand all the implementation issues. But if there really
is some reason to have this blob/non-blob decision point before calling
send(), can I suggest that instead of confusing the XHR API with
On Fri, Oct 29, 2010 at 4:08 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 29 Oct 2010 07:55:58 +0200, David Flanagan da...@davidflanagan.com
wrote:
I doubt I understand all the implementation issues. But if there really
is some reason to have this blob/non-blob decision point before
On Fri, 29 Oct 2010 13:08:07 +0200, Anne van Kesteren ann...@opera.com
wrote:
Brainstorming here. We could choose to always expose resonseArrayBuffer
and keep it together with responseText and responseXML. And for
applications that are worried about memory usage or care about very
large
I'm late to this asBlob vs. responseType party, but I tend to agree
with Boris's initial response:
4) Make things easy to use for authors; that means supporting
responseText and responseArrayBuffer, with access to both on the same
XHR object without weird restrictions and without clairvoyance
On 10/28/10 5:22 PM, David Flanagan wrote:
In fact, I'd go further and ask why the blob case needs to be special
cased at all. The bytes are stored somewhere. Returning them as a blob
doesn't seem any harder than returning them as an ArrayBuffer.
David, the issue is that if you make a request
On 10/28/2010 06:24 PM, Boris Zbarsky wrote:
On 10/28/10 5:22 PM, David Flanagan wrote:
In fact, I'd go further and ask why the blob case needs to be special
cased at all. The bytes are stored somewhere. Returning them as a blob
doesn't seem any harder than returning them as an ArrayBuffer.
