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

On 10/30/2010 09:34 AM, Jonas Sicking wrote:
> On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky<bzbarsky@mit.edu>  wrote:
>> On 10/28/10 11:29 PM, Jonas Sicking wrote:
>>>
>>> Personally I like the proposed responseType solution.
>>
>> The one where you pick one up front and it throws if you ask for something
>> else, right?
>>
>>> I agree that it has a downside in that it doesn't allow figuring out
>>> the type as data starts coming in.
>>
>> Well, that, and the whole "throws exceptions" bit...
>
> I'm not entirely following what your concern is. I.e. what usage
> pattern you are worried will either break in existing code, or people
> will get wrong in new code.
>
> My suggestion is that we add a .response property which always contain
> the result, no matter what type is being fetched. In the "default"
> mode, when .resonseType is not set, it can contain the same value as
> .responseText currently contains. If .responseType is set to "blob" it
> will return a Blob object, if it's set to "binary" it will return a
> ArrayBuffer etc.

But the existing responseText and responseXML would still work as they
work atm? They would be basically the old, sort-of-deprecated-API?
If developer wants to get stringified value from ArrayBuffer response,
she/he could use .responseText?

(Browsers could actually warn in the error console if use of old and
new API is mixed)


-Olli

Received on Monday, 1 November 2010 19:48:44 UTC