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

Re: [XHR2] responseType / response / overrideMimeType proposal

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 29 Nov 2010 11:48:57 -0800
Message-ID: <AANLkTikETMHm6xWwu1aOp87sd4EYLNM9GDvQ=a3VJ3Ux@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: WebApps WG <public-webapps@w3.org>
On Mon, Nov 29, 2010 at 9:21 AM, Anne van Kesteren <annevk@opera.com> wrote:
> Before I write it out it would be nice to assess whether there is consensus
> on this. From the current draft, asBlob, responseBlob, and
> responseArrayBuffer are removed. response and responseType are added.
>
> responseType can be set when the state is either OPENED or HEADERS_RECEIVED
> and must be set before send() is invoked for synchronous requests. When set
> at an inappropriate point it throws INVALID_STATE_ERR much like the other
> attributes. (This means responseType can be set during the request,
> specifically after all headers are available to the author so she/he can
> make an informed choice what to set responseType to.)
>
> Depending on the type response either starts returning at LOADING or DONE.
>
> overrideMimeType can be invoked whenever responseType can be set.
>
> responseType has these constants:
>
>  RESPONSE_DEFAULT
>  RESPONSE_TEXT
>  RESPONSE_DOCUMENT
>  RESPONSE_BLOB
>  RESPONSE_ARRAY_BUFFER
>
> When set to anything but RESPONSE_DEFAULT responseText and responseXML will
> throw INVALID_STATE_ERR. When set to RESPONSE_DEFAULT response returns what
> responseText returns. (This seems mildly better than throwing, but I can be
> convinced to make it throw instead.)

I'm not really loving the enum names. Why not just loose the
"RESPONSE_" prefix? There isn't a risk of name collisions anyway since
the values are namespaced under the XMLHttpRequest name. I suspect
that with names ranging from 27 to 35 characters, many of which are in
upper case which is even more awkward to type, people will either just
use the numeric values or define their own constants, both of which
reduce the legibility of the code.

I'd also be fine with using strings, but I personally like enums more
(though the reason is mostly perf which is arguably pretty silly).

/ Jonas
Received on Monday, 29 November 2010 19:49:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT