- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 26 Oct 2010 20:49:53 -0400
- To: Chris Rogers <crogers@google.com>
- CC: Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Darin Fisher <darin@google.com>, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, Geoffrey Garen <ggaren@apple.com>, jorlow@google.com
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 creates.... > 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. -Boris
Received on Wednesday, 27 October 2010 00:50:28 UTC