W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Chris Marrin <cmarrin@apple.com>
Date: Mon, 01 Nov 2010 15:35:57 -0700
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
Message-id: <B83614A8-52AB-4990-B940-F95985A50BA2@apple.com>
To: Olli@pettay.fi

On Nov 1, 2010, at 1:06 PM, Olli Pettay wrote:

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

I think they would make the implementation simpler because you wouldn't have to worry about the case of keeping around multiple versions of the data just in case the author tries to use multiple mechanisms. Adding new access mechanisms can get very cumbersome if you have to support every permutation. This might avoid that.


Received on Monday, 1 November 2010 22:36:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC