Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

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 devices are going to suffer especially from these problems.

Just due to being low on memory compared to desktops, right?

> Also, Chris Marrin
> points out that the payloads are likely to become MUCH larger when
> dealing with binary data.  It's simply wasteful to decode to text when
> it was clearly not intended to be used as text.

Well, hold on.  If that's the concern, I don't see the problem.  Store 
the binary data; only produce the text if someone asks for it.  In the 
large-binary-data cases this means you just store the binary data unless 
the text is explicitly asked for.  You just get duplication of data in 
memory in the cases that ask for the text, right?

> Performance isn't something we can just ignore.

No, but neither is it the #1 concern overriding all other 
considerations.  It's worth keeping that in mind.

> We already have an "asBlob" attribute which has the same issue.

Indeed.  I think that's a mistake too.

> If there's a different method we devise to also determine based on content-type when we receive
> the header

That doesn't solve the problem, sadly, for cases where the XHR is 
dispatched by a library.  I covered this earlier in this thread....

> This was just an alternative to having "asBlob" and "asArrayBuffer"
> attributes, where instead there's a "responseType" attribute which can
> be set up front to one of several types.

Ah, ok.

> I think we simply disagree about the performance issues involved.

Possible.  I'm quite willing to be enlightened as to the performance 
issues you are running into!

I also think we're disagreeing about the severity of the problems the 
modal "just kill the script that makes the wrong access" behavior 

>   Adding an "asArrayBuffer" or similar which can be set up-front does
> not hurt the current API which is used currently to receive text.  The
> normal API usage continues to behave as it does and would not break any
> existing libraries.

It makes it impossible to mix website code with library code, or with 
other website code, if they disagree on how to treat the response.  That 
means it involves coordination across multiple independent actors, and 
failure to coordinate just right results in hard-to-debug (likely 
timing-related, for one thing) exceptions.

> Any future libraries which will use the
> "responseArrayBuffer" attribute can easily be coded sensibly with
> "asArrayBuffer".

You're assuming that everyone will always use one or the other and never 
a mix.  I think this assumption is unfounded....

> I think that in the vast majority of use cases, it
> *will* be known up-front what the type of the data is

This is what I disagree on.  I can probably agree on "majority", but I'd 
expect a large minority to not know, especially as cross-site XHR 
becomes more common.


Received on Wednesday, 27 October 2010 00:50:28 UTC