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

On Monday, November 1, 2010, Olli Pettay <Olli.Pettay@helsinki.fi> 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?

They would work as-is is responseType is the empty string (i.e.
default). If .responseType is set to anything else they throw an
exception.

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

That would probably be a good idea too.

/ Jonas