Re: [XHR2] responseType / response / overrideMimeType proposal

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 UTC