On 10/30/2010 09:34 AM, Jonas Sicking wrote:
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky<bzbar...@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
