[XHR2] why have an asBlob attribute at all?

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

Received on Thursday, 28 October 2010 21:23:32 UTC