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

On Nov 1, 2010, at 12:47 PM, Olli Pettay wrote:

> 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)

I think we could go one step further and throw if the author used responseText or responseXML and then tried to use responseObject or responseType, and vice versa. Doing so would steer authors into the modern APIs and would make the implementor's job easier.

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

Received on Monday, 1 November 2010 19:57:49 UTC