- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Mon, 01 Nov 2010 21:06:29 +0100
- To: Chris Marrin <cmarrin@apple.com>
- CC: Jonas Sicking <jonas@sicking.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>, jorlow@google.com, jamesr@chromium.org
On 11/01/2010 08:57 PM, Chris Marrin wrote: > > 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. I doubt throwing an exception would make implementor's job significantly easier. And based on my experience in deprecating some event handling related methods, posting warnings about deprecated API to error console is surprisingly effective. -Olli
Received on Monday, 1 November 2010 20:07:26 UTC