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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 10 Nov 2010 15:00:59 -0800
Message-ID: <AANLkTimR==xEpNWhM9g7EJX8X5r9PRAmo5QA2U3X5zom@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: David Flanagan <david@davidflanagan.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org, Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.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 Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers <crogers@google.com> wrote:
>> 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
> So you prefer that .responseType take a string value as opposed to an
> integer enum value?  Darin Fisher had the idea that introspection of the
> supported values would be easier as an enum.

Yes, I think using an enum would be *extremely* verbose, particularly
given this particular API's name.  I don't want to see or type code


This is much better:

myXHR.responseType = "arraybuffer";

Received on Wednesday, 10 November 2010 23:01:54 UTC

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