Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

On Oct 25, 2010, at 3:33 PM, Boris Zbarsky wrote:

> On 10/25/10 6:21 PM, Chris Rogers wrote:
>>  People are concerned that it would require keeping two copies of the
>> data around (raw bytes, and unicode text version) since it's unknown
>> up-front whether "responseText", or "responseArrayBuffer" will be
>> accessed.
> 
> Note that Gecko does exactly that, and we've seen no problems with it...  It's very rare to have really large XHR bodies, for what it's worth.

I don't think we can say that. responseArrayBuffer is going to enable new uses of XHR. Floating point arrays for 3D mesh animation can easily get into the multi-megabyte range. I'm sure some audio client will be pushing the envelope here as well.

> 
>> This approach does seem a little strange because of the mutually
>> exclusive nature of the access.  However, it seems that it would be hard
>> to come up for a reasonable use case where both the raw bytes *and* the
>> text would be needed for the same XHR.
> 
> You could have a situation where a library dispatches the XHR for you and always looks at the text for some reason (libraries tend to do that sort of thing) while you actually want the bytes.
> 
> In general, this approach seems really fragile and hostile to web developers.
> 
>> 2. Darin Fisher has suggested this approach: Add an "asArrayBuffer"
>> attribute (similar to "asBlob") which *must* be set before sending the
>> request if there will be a subsequent access of the
>> "responseArrayBuffer" attribute.
> 
> This make it impossible to decide whether to look at the text or the bytes based on the content-type of the response (unless you allow setting the attribute in some early-enough onStateChange callback _and_ libraries expose XHRs in that early a state to consumers); having that ability seems like a desirable feature.
> 
>> 3. Get rid of the "asBlob" attribute and add a new "responseType"
>> attribute which could be:
>> "Text" <--- this is the default
>> "XML"
>> "Bytes"
>> ... other types yet to be defined
> 
> I'm not sure I follow this proposal.

This replaces everything with 3 parts:

	any responseObject(); // Return an object based on the currently requested data type
	DOMString responseType(); Return the current type setting;

The last part is adding a param to XHR.open() which specifies the desired type. For introspection you might also want a way to ask if a given type is supported, or you could have open throw an exception if it can't handle the given type for the given url. There are other ways to do the API, but that's the basic idea.

We'd of course have to support the existing API for legacy. But the above API supplants the current responseText(), responseXML(), etc.

-----
~Chris
cmarrin@apple.com

Received on Monday, 25 October 2010 23:06:18 UTC