On Mon, Aug 8, 2011 at 5:13 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
XHR Level 2 does wonders for making XMLHttpRequest better. However
there is one problem that we have run into with streaming data.
Using .responseType=text you can read the contents of the data as
soon as it
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
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
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
I don't have a strong preference either way (adding responseType to XHR, or
creating a new BinaryHttpRequest).
If we do choose the responseType approach, should its value be an enum, or a
string?
Chris
On Wed, Nov 10, 2010 at 12:44 PM, Michael Nordman micha...@google.comwrote:
Personally, I
After discussion with Anne and James, I retract my support for a new
constructor. I'm in favor of .responseType.
Specifically, .responseType would take values like (for legacy
treatment) / text / document / arraybuffer / blob / etc. If
the value is , then .responseText and .responseXML
Hi David,
Sorry for the delayed response. I think the idea of BinaryHttpRequest is a
reasonable one. As you point out, it simply side-steps any potential
performance and compatibility issues. Are you imagining that the API is
effectively the same as XMLHttpRequest, except without the text and
I just had a short talk with Darin Fisher and he suggested that instead of
.responseType taking a string value, that it could be an enum value of
XMLHttpRequest, something like:
const unsigned short RESPONSETYPE_DEFAULT = 0;
const unsigned short RESPONSETYPE_BINARY = 1;
I'm not sure I completely understand the use case with the cross-site
scripts. Are we talking about a situation where one library initiates the
XHR and another library's event listener receives the data, where it's not
aware if the data is actually text or a binary payload? I can understand
the
There's been some recent discussion in the webkit-dev mailing list about the
efficiency of implementation of the responseArrayBuffer attribute. People
are concerned that it would require keeping two copies of the data around
(raw bytes, and unicode text version) since it's unknown up-front
Based on these constraints, it sounds like we either have to live with the
fact that we'll keep both a binary copy and a text copy around as we're
receiving XHR bytes. Or, we need a way to specify up-front that we're
interested in loading as binary (before calling send()) and not handle
binary in
11 matches
Mail list logo
