On Thu, 11 Nov 2010 00:00:59 +0100, Tab Atkins Jr.
wrote:
On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers 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 legac
* 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 t
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 bi
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, par
On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers 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
* 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, whi
>
>
> 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 .responseTex
On Wed, Nov 10, 2010 at 1:39 PM, Bjoern Hoehrmann 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 both repre
* 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 synchronou
On Tue, Nov 9, 2010 at 12:03 PM, Tab Atkins Jr. wrote:
> On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers 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 com
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 wrote:
> Personally, I don't think new respo
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 ou
On Tue, 09 Nov 2010 21:03:22 +0100, Jonas Sicking wrote:
I still don't see the problem with the responseType. There's very
little difference in both BinaryHttpRequest and responseType is opt-in
mechanisms.
I am not a big fan of a new object either. It would require two new
objects, for one.
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 reasonabl
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 XMLHttpRequest
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers 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 API is
> effect
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers 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 API is
> effect
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 X
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 en
On 11/3/10 7:06 AM, Jonas Sicking wrote:
No, my concern is that browsers will implement this, and then sites that
haven't updated their jquery, and probably never plan to do it, will start
using the new stuff browsers have implemented.
But won't that always fail? If the author either sets .resp
On 11/3/10 7:15 AM, Tab Atkins Jr. wrote:
In this particular case, if someone is using jQuery to do their XHR,
they will basically never touch the native XHR object.
Why does jquery pass that object back in the response callback, then?
-Boris
On Tue, Nov 2, 2010 at 9:16 PM, Boris Zbarsky 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 various exi
On Wed, Nov 3, 2010 at 5:16 AM, Boris Zbarsky 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 various exi
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 that
On Mon, Nov 1, 2010 at 9:39 PM, Boris Zbarsky 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 libra
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 that
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;
con
On 11/02/2010 01:30 PM, James Robinson wrote:
On Tue, Nov 2, 2010 at 1:04 PM, David Flanagan mailto:da...@davidflanagan.com>> wrote:
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer will be memory inefficie
On Tue, Nov 2, 2010 at 1:04 PM, 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.
>
>
Ther
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 br
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 .resp
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 tryin
On Monday, November 1, 2010, Olli Pettay wrote:
> On 10/30/2010 09:34 AM, Jonas Sicking wrote:
>
> On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky 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
On Monday, November 1, 2010, Olli Pettay wrote:
> On 10/30/2010 09:34 AM, Jonas Sicking wrote:
>
> On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky 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
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 Zbarsky
wrote:
On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed responseType solution.
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 Zbarsky wrote:
>>> On 10/28/10 11:29 PM, Jonas Sicking wrote:
Personally I like the proposed responseType solution.
>>>
>>> The one where you pick
On 10/30/2010 09:34 AM, Jonas Sicking wrote:
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky 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 ag
On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky 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 that
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 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
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 Thu, Oct 28, 2010 at 8:37 PM, Boris Zbarsky 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/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.
In this case there is a very large amount of
content out there today that us
On Thu, Oct 28, 2010 at 10:33 AM, Maciej Stachowiak 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
>> poi
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 o
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
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 c
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 acc
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 don
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
>> circumstance
>> 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 st
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 tags).
On Wed, Oct 27, 2010 at 12:34 PM, Boris Zbarsky 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 decomposition
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 that
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
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 su
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
On Wed, Oct 27, 2010 at 2:10 PM, Boris Zbarsky 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 webkit fol
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 think.
On Wed, 27 Oct 2010 02:43:58 +0200, Boris Zbarsky 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 page explicitly
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 questio
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 sufficie
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 would
On Wed, Oct 27, 2010 at 12:12 AM, Boris Zbarsky 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 prod
On Wed, Oct 27, 2010 at 12:04 AM, Boris Zbarsky 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 data to d
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 talkin
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 hinting
On Mon, 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 "responseArray
On Tue, Oct 26, 2010 at 5:43 PM, Boris Zbarsky 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 page e
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 re
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 d
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 ma
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 paramete
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
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
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 wrote:
>
>
> On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky wrote:
>
>> On 10/25/10 6:21 PM, Chris Rogers wrote
On Mon, 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 "responseArray
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
On Tue, 26 Oct 2010 00:33:35 +0200, Boris Zbarsky 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 string
representat
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 blindl
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
if
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
JavaScript
On Mon, Oct 25, 2010 at 11: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 "responseArra
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
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 do
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
accessed.
Note that Gecko does exactly that, and
On Mon, Oct 25, 2010 at 3:21 PM, Chris Rogers 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
> around (raw byt
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 wheth
88 matches
Mail list logo