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

On Tue, Nov 9, 2010 at 12:03 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers <crogers@google.com> wrote:
>> Hi David,
>> Sorry for the delayed response.  I think the idea of BinaryHttpRequest is a
>> reasonable one.  As you point out, it simply side-steps any potential
>> performance and compatibility issues.  Are you imagining that the API is
>> effectively the same as XMLHttpRequest, except without the text and XML
>> part?
>> How do other people feel about David's proposal?
>
> I'm in favor a new constructor.  It seems silly to first hack
> ourselves into a corner by extending an API designed for text or XML,
> then try to hack our way out of the problems that causes.  A new
> object that does what's needed seems like the cleanest and most
> correct solution to the problem.

After discussion with Anne and James, I retract my support for a new
constructor.  I'm in favor of .responseType.

Specifically, .responseType would take values like "" (for legacy
treatment) / "text" / "document" / "arraybuffer" / "blob" / etc.  If
the value is "", then .responseText and .responseXML are filled
appropriately, while .response is empty.  Otherwise, .responseText and
.responseXML are empty (or throw or something), while .response
contains the value in the chosen format.  .responseType must be set at
some appropriately early time; after the response is received, changes
to .responseType are ignored or throw.

~TJ

Received on Wednesday, 10 November 2010 21:39:04 UTC