Personally, I don't think new response modes is the proverbial straw
that breaks the camel's back.
I don't see the problem with selecting the responseType up front
either. It doesn't feel like a new class of object is warranted just
to provide the response body different forms. As Jonas pointed
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
On Tue, Nov 9, 2010 at 12:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers crog...@google.com wrote:
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
* David Flanagan wrote:
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer will be memory inefficient because implementations
will end up with both representations in memory.
James (Google) worries that synchronously
On Wed, Nov 10, 2010 at 1:39 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* David Flanagan wrote:
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer will be memory inefficient because implementations
will end up with
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
* Jonas Sicking wrote:
In most cases you do not need to store the bytes in order to get them
back, you can just apply the character encoding scheme used to decode
the bytes to the string and you'll have the original byte string, so
long as the character encoding scheme is bijective, which is
On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers crog...@google.com wrote:
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
On 11/10/2010 03:00 PM, Tab Atkins Jr. wrote:
So you prefer that .responseType take a string value as opposed to an
integer enum value? Darin Fisher had the idea that introspection of the
supported values would be easier as an enum.
Yes, I think using an enum would be *extremely* verbose,
On 11/10/10 4:39 PM, Bjoern Hoehrmann wrote:
In most cases you do not need to store the bytes in order to get them
back, you can just apply the character encoding scheme used to decode
the bytes to the string and you'll have the original byte string, so
long as the character encoding scheme is
* Boris Zbarsky wrote:
On 11/10/10 4:39 PM, Bjoern Hoehrmann wrote:
In most cases you do not need to store the bytes in order to get them
back, you can just apply the character encoding scheme used to decode
the bytes to the string and you'll have the original byte string, so
long as the
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
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers crog...@google.com wrote:
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
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers crog...@google.com wrote:
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
On 11/9/10 2:54 PM, Chris Rogers wrote:
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
On 11/09/2010 11:54 AM, Chris Rogers wrote:
Hi David,
Sorry for the delayed response.
No problem. public-webapps got strangely quiet after I sent my last
message, and I realized that everyone was off actually meeting about
this stuff...
I think the idea of BinaryHttpRequest
is a
On Wed, Nov 3, 2010 at 5:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/2/10 11:35 PM, Jonas Sicking wrote:
So your concern is that jQuery will update to use the new API before
browsers implement it. And then once browsers do implement it and
start honoring the .responseType by making
On Tue, Nov 2, 2010 at 9:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/2/10 11:35 PM, Jonas Sicking wrote:
So your concern is that jQuery will update to use the new API before
browsers implement it. And then once browsers do implement it and
start honoring the .responseType by making
On 11/02/2010 07:06 PM, Boris Zbarsky wrote:
On 11/2/10 4:04 PM, David Flanagan wrote:
Boris (Mozilla) worries that creating a new mode in which responseText
is unavailable will break jQuery applications.
And various others where the consumer of the data and the XHR creator
are not the same
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer will be memory inefficient because implementations
will end up with both representations in memory.
James (Google) worries that synchronously reading bytes from the
On Tue, Nov 2, 2010 at 1:04 PM, David Flanagan da...@davidflanagan.comwrote:
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer will be memory inefficient because implementations will
end up with both representations
On 11/02/2010 01:30 PM, James Robinson wrote:
On Tue, Nov 2, 2010 at 1:04 PM, David Flanagan da...@davidflanagan.com
mailto:da...@davidflanagan.com wrote:
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer
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;
On 11/2/10 4:04 PM, David Flanagan wrote:
Boris (Mozilla) worries that creating a new mode in which responseText
is unavailable will break jQuery applications.
And various others where the consumer of the data and the XHR creator
are not the same entity. jQuery is just an obvious example
On Mon, Nov 1, 2010 at 9:39 PM, Boris Zbarsky bzbar...@mit.edu wrote:
As long as only one entity is doing the expecting, right? Right now
jquery
expects to get responseText, so if you expect something else you can't
use
jquery's XHR wrappers, say
I'm not terribly worried about library
On 11/2/10 11:35 PM, Jonas Sicking wrote:
So your concern is that jQuery will update to use the new API before
browsers implement it. And then once browsers do implement it and
start honoring the .responseType by making various existing properties
throw, things will fail?
No, my concern is
On 10/30/2010 09:34 AM, Jonas Sicking wrote:
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarskybzbar...@mit.edu wrote:
On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed responseType solution.
The one where you pick one up front and it throws if you ask for something
On Nov 1, 2010, at 12:47 PM, Olli Pettay wrote:
On 10/30/2010 09:34 AM, Jonas Sicking wrote:
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarskybzbar...@mit.edu wrote:
On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed responseType solution.
The one where you pick
On 11/01/2010 08:57 PM, Chris Marrin wrote:
On Nov 1, 2010, at 12:47 PM, Olli Pettay wrote:
On 10/30/2010 09:34 AM, Jonas Sicking wrote:
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarskybzbar...@mit.edu
wrote:
On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed
On Monday, November 1, 2010, Olli Pettay olli.pet...@helsinki.fi wrote:
On 10/30/2010 09:34 AM, Jonas Sicking wrote:
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarskybzbar...@mit.edu wrote:
On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed responseType solution.
On Monday, November 1, 2010, Olli Pettay olli.pet...@helsinki.fi wrote:
On 10/30/2010 09:34 AM, Jonas Sicking wrote:
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarskybzbar...@mit.edu wrote:
On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed responseType solution.
On 10/30/10 3:34 AM, Jonas Sicking wrote:
I'm not entirely following what your concern is. I.e. what usage
pattern you are worried will either break in existing code, or people
will get wrong in new code.
Well, one simple usage pattern is using the jquery get me some stuff
API and then trying
On Nov 1, 2010, at 1:06 PM, Olli Pettay wrote:
...But the existing responseText and responseXML would still work as
they work atm? They would be basically the old,
sort-of-deprecated-API? If developer wants to get stringified value
from ArrayBuffer response, she/he could use .responseText?
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed responseType solution.
The one where you pick one up front and it throws if you ask for something
else, right?
I agree that it has a downside in
On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed responseType solution.
The one where you pick one up front and it throws if you ask for
something else, right?
I agree that it has a downside in that it doesn't allow figuring out
the type as data starts coming in.
On Oct 27, 2010, at 5:36 PM, Boris Zbarsky wrote:
But both approaches would reliably throw exceptions if a client got things
wrong.
See, there's the thing. Neither approach is all that reliable (even to the
point of throwing sometimes but not others for identical code), and access is
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
I think a good rule for any web API is that the user's needs come before the
author's needs. In this case there is a very large amount of content out
there today that uses XMLHttpRequest to download data, sometimes significant
amounts of data, and that use .responseText exclusively to access that
On 10/28/10 5:40 PM, Chris Rogers wrote:
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
On Thu, Oct 28, 2010 at 10:33 AM, Maciej Stachowiak m...@apple.com wrote:
On Oct 27, 2010, at 5:36 PM, Boris Zbarsky wrote:
But both approaches would reliably throw exceptions if a client got things
wrong.
See, there's the thing. Neither approach is all that reliable (even to the
point
On Thu, Oct 28, 2010 at 8:37 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/28/10 9:11 PM, James Robinson wrote:
I think a good rule for any web API is that the user's needs come before
the author's needs.
And the author's before the implementor's, right?
OK, let's take that as given.
On 10/29/10 12:15 AM, James Robinson wrote:
Are we talking about ArrayBuffer here or Blob?
The former.
It's never acceptable to block javascript on a synchronous disk access
Why?
Other questions to consider:
1) Why is it ok to block it on a synchronous disk access due to being
paged in
On Oct 28, 2010, at 9:41 PM, Boris Zbarsky wrote:
On 10/29/10 12:15 AM, James Robinson wrote:
Are we talking about ArrayBuffer here or Blob?
The former.
It's never acceptable to block javascript on a synchronous disk access
Why?
Other questions to consider:
1) Why is it ok to
On Tue, Oct 26, 2010 at 5:43 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/26/10 5:27 AM, Anne van Kesteren wrote:
Boris, do you see value in the asBlob / responseBlob proposal currently
in the draft?
The idea there being that you don't have to have the data in memory at all
unless the
On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/25/10 6:21 PM, Chris Rogers wrote:
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 whether responseText, or
On 10/27/10 2:28 AM, Darin Fisher wrote:
I think it's about performance as well as implementor convenience. If
the implementor knows up front that the data should be stored as a Blob,
then the implementor can write the data to disk without having to waste
memory.
I have no problem with
On 10/27/10 2:39 AM, Darin Fisher wrote:
I think XMLHttpRequest is trying to be too much of a kitchen-sink.
OK, something we agree on. ;)
Ideally, there'd be separate components that operate on an ArrayBuffer
and produce a decoded string / XML document. Then, for the use case you
are
On Wed, Oct 27, 2010 at 12:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/27/10 2:28 AM, Darin Fisher wrote:
I think it's about performance as well as implementor convenience. If
the implementor knows up front that the data should be stored as a Blob,
then the implementor can write the
On Wed, Oct 27, 2010 at 12:12 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/27/10 2:39 AM, Darin Fisher wrote:
I think XMLHttpRequest is trying to be too much of a kitchen-sink.
OK, something we agree on. ;)
Ideally, there'd be separate components that operate on an ArrayBuffer
and
On 10/27/10 3:21 AM, Darin Fisher wrote:
I have no problem with hinting to the implementor that the result is
expected to be used as a Blob so they can optimistically store it to
disk. My problem is with then making it impossible to get it as a
string if needed later (which
On 10/27/10 3:24 AM, Darin Fisher wrote:
So, it sounds like we just need to present you with some concrete
examples of XHRs being used to fetch large responses as Text or XML, and
then you will be convinced?
Uh... no. I'm sure these happen. The question is whether their
existence is
On 10/27/10 3:40 AM, Boris Zbarsky wrote:
On 10/27/10 3:24 AM, Darin Fisher wrote:
So, it sounds like we just need to present you with some concrete
examples of XHRs being used to fetch large responses as Text or XML, and
then you will be convinced?
Uh... no. I'm sure these happen. The
On Wed, 27 Oct 2010 02:43:58 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/26/10 5:27 AM, Anne van Kesteren wrote:
Boris, do you see value in the asBlob / responseBlob proposal currently
in the draft?
The idea there being that you don't have to have the data in memory at
all unless the
On 10/27/10 5:54 AM, Anne van Kesteren wrote:
Okay, so even for responseBlob you think it should be the implementor
handling the complexity.
I think we should at least seriously consider that, yes.
I realize the webkit folks will disagree en masse. ;)
Would be good to hear what others
On Wed, Oct 27, 2010 at 2:10 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/27/10 5:54 AM, Anne van Kesteren wrote:
Okay, so even for responseBlob you think it should be the implementor
handling the complexity.
I think we should at least seriously consider that, yes.
I realize the
Hi Boris.
As long as the same object provides both views and the views are mutually
exclusive, it's really easy for the dispatcher to change what they ask for
and subtly break other consumers he doesn't even know about.
To the contrary, I think eliminating subtlety is the main benefit of
Darin mentioned it earlier in this thread, having XHR return the raw data
and providing other interfaces to interpret/decode the raw data into
strings/xmlDocs. I like that decomposition.
Because I'm skeptical that nested libraries trying to access the data both
ways will be an issue.
I'm not
On 10/27/10 2:56 PM, Geoffrey Garen wrote:
Quietly providing multiple copies of data creates a subtle memory use problem.
Yes, agreed.
Explicitly throwing an exception at the site that tries to access the data in
the wrong way obviously and immediately points a finger at the problem.
Sort
On 10/27/10 3:23 PM, Michael Nordman wrote:
Darin mentioned it earlier in this thread, having XHR return the raw
data and providing other interfaces to interpret/decode the raw data
into strings/xmlDocs. I like that decomposition.
If we were designing from scratch, yes.
Or is the proposal
On Wed, Oct 27, 2010 at 12:34 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/27/10 3:23 PM, Michael Nordman wrote:
Darin mentioned it earlier in this thread, having XHR return the raw
data and providing other interfaces to interpret/decode the raw data
into strings/xmlDocs. I like that
On 10/27/10 3:46 PM, Michael Nordman wrote:
Note, by the way, that for XML and HTML types, one is required (per
current XHR spec) to instantiate an XML or HTML parser,
respectively, to produce the responseText (because the data can
declare its own encoding in things like meta
Explicitly throwing an exception at the site that tries to access the data
in the wrong way obviously and immediately points a finger at the problem.
Sort of. Except the failure happens at runtime in uncontrolled circumstances
and people tend to sprinkle try-and-ignore-exceptions stuff in
On Oct 27, 2010, at 3:14 PM, Geoffrey Garen wrote:
Explicitly throwing an exception at the site that tries to access the data
in the wrong way obviously and immediately points a finger at the problem.
Sort of. Except the failure happens at runtime in uncontrolled
circumstances and
On 10/27/10 6:14 PM, Geoffrey Garen wrote:
But, now clarified, your objection is about a much more minor case than
originally specified: In the case of an intervening layer that not only wraps
an XHR but also reads its data behind the scenes
Which is all of them that I've seen. I haven't
On Tue, 26 Oct 2010 00:33:35 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
[...]
Boris, do you see value in the asBlob / responseBlob proposal currently in
the draft? Maybe we should keep that for very large responses. For the
other scenarios it is probably fine to have both a octet and
25.10.2010, в 16:36, Boris Zbarsky написал(а):
That may become more common when people start downloading arbitrary files,
and storing them to disk with FileWriter. But even years ago, we've been
getting performance bugs forcing us to ensure responseText didn't have to be
copied for
I'm in favor of adding the explicit asArrayBuffer attribute. Simple and
straight forward for both web developers and browser developers.
On Tue, Oct 26, 2010 at 3:39 PM, Chris Rogers crog...@google.com wrote:
On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On
On Oct 25, 2010, at 4:07 PM, Jeremy Orlow wrote:
...3. Get rid of the asBlob attribute and add a new responseType
attribute which could be:
Text --- this is the default
XML
Bytes
... other types yet to be defined
I'm not sure I follow this proposal.
The parameter would be added to
On Oct 25, 2010, at 4:51 PM, Boris Zbarsky wrote:
On 10/25/10 7:05 PM, Chris Marrin wrote:
I don't think we can say that. responseArrayBuffer is going to enable new
uses of XHR. Floating point arrays for 3D mesh animation can easily get into
the multi-megabyte range.
Hmm... But will
Chris Marrin wrote:
On Oct 25, 2010, at 4:07 PM, Jeremy Orlow wrote:
...3. Get rid of the asBlob attribute and add a new responseType
attribute which could be:
Text --- this is the default
XML
Bytes
... other types yet to be defined
I'm not sure I follow this proposal.
The parameter would be
On 10/26/10 5:27 AM, Anne van Kesteren wrote:
Boris, do you see value in the asBlob / responseBlob proposal currently
in the draft?
The idea there being that you don't have to have the data in memory at
all unless the page explicitly asks for it, and then giving the page the
option of only
On 10/26/10 6:39 PM, Chris Rogers wrote:
Alexey and James Robinson from Google have experienced noticeable
performance-related issues with keeping two copies.
OK, what sort? And again, was the problem with keeping both in
perpetuity, or with having both live at any point in time?
Mobile
On 10/26/10 7:55 PM, Chris Marrin wrote:
Hmm... But will people still be accessing .responseText on those? And if so,
wouldn't they be broken by the proposals so far in this thread?
Probably not. But you'd either need to convert data from the raw form to the
desired form on every call to
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
On Mon, Oct 25, 2010 at 3:21 PM, Chris Rogers crog...@google.com wrote:
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
25.10.2010, в 15:33, Boris Zbarsky написал(а):
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 whether responseText, or responseArrayBuffer will be
accessed.
Note that Gecko does exactly
On Oct 25, 2010, at 3:33 PM, Boris Zbarsky wrote:
On 10/25/10 6:21 PM, Chris Rogers wrote:
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 whether responseText, or responseArrayBuffer will be
On Mon, Oct 25, 2010 at 11:33 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/25/10 6:21 PM, Chris Rogers wrote:
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 whether responseText, or
On 10/25/10 6:42 PM, Alexey Proskuryakov wrote:
That may become more common when people start downloading arbitrary files, and
storing them to disk with FileWriter. But even years ago, we've been getting
performance bugs forcing us to ensure responseText didn't have to be copied for
On 10/25/10 7:05 PM, Chris Marrin wrote:
I don't think we can say that. responseArrayBuffer is going to enable new uses
of XHR. Floating point arrays for 3D mesh animation can easily get into the
multi-megabyte range.
Hmm... But will people still be accessing .responseText on those? And
On 10/25/10 7:07 PM, Jeremy Orlow wrote:
Can you think of any use cases where a developer would need both though?
Most any use case where there are multiple developers involved (page +
library, multiple people working on scripts in the page, whatever) and
some want the bytes and others
81 matches
Mail list logo
