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 required
on the part of the author. If UAs feel that they don't want to keep
both copies of the data in memory on a permanent basis, they can
optimize this by dropping the responseText (on a timer or via a
low-memory detection mechanism, or in various other ways) and
regenerating it from the raw bytes as needed.
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.
This is not a rhetorical question. As a web developer reading the XHR2
spec, I do not get why there is one type of response that I have to
request specially.
Searching through the archives just now I found this from June:
> >>> XHR will have a responseBlob property.
> >>> In order to signal the XHR that it should spool to disk and supply
> >>> responseBlob, a flag must be set before send() is called.
I know that Blobs are an outgrowth of the File API, but won't many Blobs
(created by BlobBuilders, for example) be in-memory objects rather than
on-disk objects? And shouldn't the decision about whether to spool a
response to disk or not be implementation-dependent? It seems to me
that an implementation might want to take a look at the Content-Length
header and spool any response > 1M, for example to disk and then memory
map it to make it look like it is in memory. This might be a good
strategy even if the response is going to be decoded into text rather
than treated as a blob.
It seems to me that the Blob case is really the primordial response
type. responseArrayBuffer, responseText and responseXML are views of the
underlying Blob. So why not just get rid of asBlob altogether?
(Probably because I'm missing something fundamental about the nature of
Blobs... I'd love to know what it is!)
David Flanagan
