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

Re: [XHR2] responseType / response / overrideMimeType proposal

From: Chris Rogers <crogers@google.com>
Date: Mon, 29 Nov 2010 14:47:41 -0800
Message-ID: <AANLkTikhXTXb_H2ShwoOr_ZbqQ2=aovaBobhMV+i=WaT@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
I don't think that performance should be very much of an issue since
.responseType would normally only be set once.  The performance hit is
negligible, and the string version seems to be clearer to use.

Chris

On Mon, Nov 29, 2010 at 11:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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 22:48:11 GMT

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