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 think strings would work much better than enumerated values.  The problem
with explicitly enumerated values is that they are extremely verbose and not
easily extensible. Using strings would allow for more natural values
("text", "blob", etc) and allow for vendor prefixing experimental extensions
without leaving odd gaps in the enum values.  For example, if/when browsers
adopt the new binary data proposal from TC39 we will probably want to
deprecate or drop RESPONSE_ARRAY_BUFFER in favor of whatever the new type
is.

Otherwise I think this looks great.

- James



>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>