Re: [XHR2] responseType / response / overrideMimeType proposal
On Mon, 29 Nov 2010 18:21:44 +0100, Anne van Kesteren ann...@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. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ responseType takes the empty string, text, document, and blob as values. I left out arraybuffer awaiting TC39 verdict. I waited with overrideMimeType changes. Can we actually start throwing for it? Anyone a good proposal for how it should work? responseText throws when responseType is not the empty string or text. responseXML throws when responseType is not the empty string or document. response returns responseText by default and never throws. When responseType is blob response always returns a Blob object, potentially empty if the response entity body is empty. (I also removed followRedirects because its design was controversial.) Feedback very much appreciated. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] responseType / response / overrideMimeType proposal
On Mon, Nov 29, 2010 at 9:21 AM, Anne van Kesteren ann...@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/
Re: [XHR2] responseType / response / overrideMimeType proposal
On Mon, Nov 29, 2010 at 9:21 AM, Anne van Kesteren ann...@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
Re: [XHR2] responseType / response / overrideMimeType proposal
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 jo...@sicking.cc wrote: On Mon, Nov 29, 2010 at 9:21 AM, Anne van Kesteren ann...@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
Re: [XHR2] responseType / response / overrideMimeType proposal
Anne, for what it's worth, in my initial implementation in WebKit, I've allowed .responseText to be accessed (without throwing) if .responseType == text. Likewise, .responseXML can be accessed (without throwing) if .responseType == document I don't have a strong opinion either way. But it wasn't hard for us to implement that way. Chris On Mon, Nov 29, 2010 at 9:21 AM, Anne van Kesteren ann...@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.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] responseType / response / overrideMimeType proposal
On Mon, Nov 29, 2010 at 3:00 PM, Chris Rogers crog...@google.com wrote: Anne, for what it's worth, in my initial implementation in WebKit, I've allowed .responseText to be accessed (without throwing) if .responseType == text. Likewise, .responseXML can be accessed (without throwing) if .responseType == document I don't have a strong opinion either way. But it wasn't hard for us to implement that way. IIRC, in our current experimental implementation accessing .responseText and .responseXML *never* throw based on .responseType - they're just empty if .responseType is wrong for them. ~TJ
Re: [XHR2] responseType / response / overrideMimeType proposal
Actually, that's not quite true. The WebKit prototype *does* throw when .responseText or .responseXML is accessed, but .responseType is not compatible (for example, arraybuffer, or blob) IIRC, in our current experimental implementation accessing .responseText and .responseXML *never* throw based on .responseType - they're just empty if .responseType is wrong for them. ~TJ
