Re: [XHR2] ArrayBuffer integration
On Tue, 28 Sep 2010 03:22:13 +0200, Michael Nordman micha...@google.com wrote: A couple of us have been looking at webkit's XHR impl and realized that to support performant access to the response via responseArrayBuffer and responseText would cause us to keep two copies of the data around, a raw data buffer and the second decoded text buffer. Considering the overwhelming number of responseText only use cases, it would be nice to not incur extra costs to support a new binary accessor which would be rarely used compared to the text accessor. So some way of making these mutually exclusive in the API. I was a bit wary already with responseBlob, but should we really punt all the complexity to authors? On top of that, how should overrideMimeType be designed if not the way it is currently in the specification. As now it effectively requires keeping the raw octets around. Should we have an asArrayBuffer attribute (or similar) to tell XHR up front how the caller wishes to access the response? Or maybe specify the accessors such that when you use responseText you can not later access responseArrayBuffer and vice versa? Are there any use cases where you'd need it both ways? I'm not sure. But you could just lazily construct the data based on what the author requests. If there are no use cases it is unlikely they will use both. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
On 9/28/10 8:09 AM, Anne van Kesteren wrote: On Tue, 28 Sep 2010 03:22:13 +0200, Michael Nordman micha...@google.com wrote: A couple of us have been looking at webkit's XHR impl and realized that to support performant access to the response via responseArrayBuffer and responseText would cause us to keep two copies of the data around, a raw data buffer and the second decoded text buffer. For what it's worth, Gecko does this. It's needed anyway to support responseText read during the load (which does happen on the web), since the relevant charset can change as the document is parsed, last I checked It kinda sucks but there it is. In practice, we handle this by lazily generating responseText on demand. On top of that, how should overrideMimeType be designed if not the way it is currently in the specification. As now it effectively requires keeping the raw octets around. Yep. I don't see this as a problem, fwiw. I'm not sure. But you could just lazily construct the data based on what the author requests. If there are no use cases it is unlikely they will use both. You can't lazily construct the original byte stream from the responseText, fwiw. So I'm not quite following how that paragraph would address Michael's concerns. -Boris
Re: [XHR2] ArrayBuffer integration
On Tue, 28 Sep 2010 14:37:30 +0200, Boris Zbarsky bzbar...@mit.edu wrote: I'm not sure. But you could just lazily construct the data based on what the author requests. If there are no use cases it is unlikely they will use both. You can't lazily construct the original byte stream from the responseText, fwiw. I guess that fails for invalid characters, indeed. Though presumably they might be somewhere still if it is being cached? So I'm not quite following how that paragraph would address Michael's concerns. Yeah sorry. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
On 9/28/10 9:25 AM, Anne van Kesteren wrote: On Tue, 28 Sep 2010 14:37:30 +0200, Boris Zbarsky bzbar...@mit.edu wrote: I'm not sure. But you could just lazily construct the data based on what the author requests. If there are no use cases it is unlikely they will use both. You can't lazily construct the original byte stream from the responseText, fwiw. I guess that fails for invalid characters, indeed. Though presumably they might be somewhere still if it is being cached? I did consider mentioning that the original byte stream can be stored on disk, yeah. At least if memory is tight. But then again, I'm not sure what the persistent storage situation actually looks like nowadays on devices with small memories. -Boris
Re: [XHR2] ArrayBuffer integration
On Sep 27, 2010, at 6:22 PM, Michael Nordman wrote: A couple of us have been looking at webkit's XHR impl and realized that to support performant access to the response via responseArrayBuffer and responseText would cause us to keep two copies of the data around, a raw data buffer and the second decoded text buffer. Considering the overwhelming number of responseText only use cases, it would be nice to not incur extra costs to support a new binary accessor which would be rarely used compared to the text accessor. So some way of making these mutually exclusive in the API. Should we have an asArrayBuffer attribute (or similar) to tell XHR up front how the caller wishes to access the response? Or maybe specify the accessors such that when you use responseText you can not later access responseArrayBuffer and vice versa? Are there any use cases where you'd need it both ways? I'd hate the idea of another flag in XHR. Why not just keep the raw bits and then convert when responseText is called? The only disadvantage of this is when the author makes multiple calls to responseText and I would not think that is a very common use case. - ~Chris cmar...@apple.com
Re: [XHR2] ArrayBuffer integration
On 9/28/10 10:32 AM, Chris Marrin wrote: I'd hate the idea of another flag in XHR. Why not just keep the raw bits and then convert when responseText is called? The only disadvantage of this is when the author makes multiple calls to responseText and I would not think that is a very common use case. It's actually reasonably common; Gecko had some performance bugs filed on us until we started caching the responseText (before that we did exactly what you just suggested). Oh, and some sites poll responseText from progress events for reasons I can't fathom. -Boris
Re: [XHR2] ArrayBuffer integration
On Tue, Sep 28, 2010 at 9:39 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/28/10 10:32 AM, Chris Marrin wrote: I'd hate the idea of another flag in XHR. Why not just keep the raw bits and then convert when responseText is called? The only disadvantage of this is when the author makes multiple calls to responseText and I would not think that is a very common use case. It's actually reasonably common; Gecko had some performance bugs filed on us until we started caching the responseText (before that we did exactly what you just suggested). Oh, and some sites poll responseText from progress events for reasons I can't fathom. A number of sites check .responseText.length on every progress event in order to monitor how much data has been received. This came up as a performance hotspot when I was profiling WebKit's XHR implementation as well. - James -Boris
Re: [XHR2] ArrayBuffer integration
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 the default case. Chris On Tue, Sep 28, 2010 at 12:05 PM, James Robinson jam...@google.com wrote: On Tue, Sep 28, 2010 at 9:39 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/28/10 10:32 AM, Chris Marrin wrote: I'd hate the idea of another flag in XHR. Why not just keep the raw bits and then convert when responseText is called? The only disadvantage of this is when the author makes multiple calls to responseText and I would not think that is a very common use case. It's actually reasonably common; Gecko had some performance bugs filed on us until we started caching the responseText (before that we did exactly what you just suggested). Oh, and some sites poll responseText from progress events for reasons I can't fathom. A number of sites check .responseText.length on every progress event in order to monitor how much data has been received. This came up as a performance hotspot when I was profiling WebKit's XHR implementation as well. - James -Boris
Re: [XHR2] ArrayBuffer integration
fwiw, specifying up front is what FileReader appears to do: http://dev.w3.org/2006/webapi/FileAPI/#dfn-filereader Of course, there are different methods in that case. dave On Tue, Sep 28, 2010 at 3:12 PM, Chris Rogers crog...@google.com wrote: 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 the default case. Chris On Tue, Sep 28, 2010 at 12:05 PM, James Robinson jam...@google.com wrote: On Tue, Sep 28, 2010 at 9:39 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/28/10 10:32 AM, Chris Marrin wrote: I'd hate the idea of another flag in XHR. Why not just keep the raw bits and then convert when responseText is called? The only disadvantage of this is when the author makes multiple calls to responseText and I would not think that is a very common use case. It's actually reasonably common; Gecko had some performance bugs filed on us until we started caching the responseText (before that we did exactly what you just suggested). Oh, and some sites poll responseText from progress events for reasons I can't fathom. A number of sites check .responseText.length on every progress event in order to monitor how much data has been received. This came up as a performance hotspot when I was profiling WebKit's XHR implementation as well. - James -Boris
Re: [XHR2] ArrayBuffer integration
A couple of us have been looking at webkit's XHR impl and realized that to support performant access to the response via responseArrayBuffer and responseText would cause us to keep two copies of the data around, a raw data buffer and the second decoded text buffer. Considering the overwhelming number of responseText only use cases, it would be nice to not incur extra costs to support a new binary accessor which would be rarely used compared to the text accessor. So some way of making these mutually exclusive in the API. Should we have an asArrayBuffer attribute (or similar) to tell XHR up front how the caller wishes to access the response? Or maybe specify the accessors such that when you use responseText you can not later access responseArrayBuffer and vice versa? Are there any use cases where you'd need it both ways? -Michael On Fri, Sep 24, 2010 at 5:41 PM, Kenneth Russell k...@google.com wrote: On Fri, Sep 24, 2010 at 5:36 PM, Jian Li jia...@chromium.org wrote: I plan to add ArrayBuffer support to BlobBuilder and FileReader. Chris, it is good that you would pick up the work for XHR. We can talk about how we're going to add ArrayBufferView to read ArrayBuffer. All of the Typed Array view types (Uint8Array, Float32Array, etc.) except for Float64Array are already implemented in WebKit. The major missing one for file and network I/O is DataView. -Ken Jian On Fri, Sep 24, 2010 at 5:23 PM, Kenneth Russell k...@google.com wrote: On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thanks, this is great and very exciting. This motivates implementing the proposed DataView interface ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6 ), which will make it easier to read multi-byte values with specified endianness out of an ArrayBuffer. For WebKit I've filed https://bugs.webkit.org/show_bug.cgi?id=46541 . -Ken (You can also do send(ArrayBuffer) obviously. I personally think supporting this for both BlobBuilder and send() makes sense. That way Blob/File etc. work too.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thanks, this is great and very exciting. This motivates implementing the proposed DataView interface ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6 ), which will make it easier to read multi-byte values with specified endianness out of an ArrayBuffer. For WebKit I've filed https://bugs.webkit.org/show_bug.cgi?id=46541 . -Ken (You can also do send(ArrayBuffer) obviously. I personally think supporting this for both BlobBuilder and send() makes sense. That way Blob/File etc. work too.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
I plan to add ArrayBuffer support to BlobBuilder and FileReader. Chris, it is good that you would pick up the work for XHR. We can talk about how we're going to add ArrayBufferView to read ArrayBuffer. Jian On Fri, Sep 24, 2010 at 5:23 PM, Kenneth Russell k...@google.com wrote: On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thanks, this is great and very exciting. This motivates implementing the proposed DataView interface ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6 ), which will make it easier to read multi-byte values with specified endianness out of an ArrayBuffer. For WebKit I've filed https://bugs.webkit.org/show_bug.cgi?id=46541 . -Ken (You can also do send(ArrayBuffer) obviously. I personally think supporting this for both BlobBuilder and send() makes sense. That way Blob/File etc. work too.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
On Fri, Sep 24, 2010 at 5:36 PM, Jian Li jia...@chromium.org wrote: I plan to add ArrayBuffer support to BlobBuilder and FileReader. Chris, it is good that you would pick up the work for XHR. We can talk about how we're going to add ArrayBufferView to read ArrayBuffer. All of the Typed Array view types (Uint8Array, Float32Array, etc.) except for Float64Array are already implemented in WebKit. The major missing one for file and network I/O is DataView. -Ken Jian On Fri, Sep 24, 2010 at 5:23 PM, Kenneth Russell k...@google.com wrote: On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thanks, this is great and very exciting. This motivates implementing the proposed DataView interface ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6 ), which will make it easier to read multi-byte values with specified endianness out of an ArrayBuffer. For WebKit I've filed https://bugs.webkit.org/show_bug.cgi?id=46541 . -Ken (You can also do send(ArrayBuffer) obviously. I personally think supporting this for both BlobBuilder and send() makes sense. That way Blob/File etc. work too.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ (You can also do send(ArrayBuffer) obviously. I personally think supporting this for both BlobBuilder and send() makes sense. That way Blob/File etc. work too.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
- Original Message - On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) How about http://bit.ly/TypedArray-spec ? :) - Vlad
Re: [XHR2] ArrayBuffer integration
On 08.09.2010 17:35, Anne van Kesteren wrote: ... Okay. I guess we can all add support for it and see who screams :-) I can certainly add this to XMLHttpRequest Level 2 and have been wanting to do that since forever. As you might have seen notes to that effect are in the specification. send() can be overloaded as per usual. Currently the proposal for the response member is responseBody which nicely maps to HTTP entity body. ... It does, but doesn't it clash with responseBody in Microsoft's ActiveX control? (http://msdn.microsoft.com/en-us/library/ms534368%28v=VS.85%29.aspx) Best regards, Julian
Re: [XHR2] ArrayBuffer integration
On Wed, Sep 8, 2010 at 8:44 AM, Julian Reschke julian.resc...@gmx.de wrote: On 08.09.2010 17:35, Anne van Kesteren wrote: ... Okay. I guess we can all add support for it and see who screams :-) I can certainly add this to XMLHttpRequest Level 2 and have been wanting to do that since forever. As you might have seen notes to that effect are in the specification. send() can be overloaded as per usual. Currently the proposal for the response member is responseBody which nicely maps to HTTP entity body. ... It does, but doesn't it clash with responseBody in Microsoft's ActiveX control? (http://msdn.microsoft.com/en-us/library/ms534368%28v=VS.85%29.aspx) Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. -Ken
