- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Mon, 01 Nov 2010 20:47:37 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, Maciej Stachowiak <mjs@apple.com>, Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, jorlow@google.com, jamesr@chromium.org
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