Re: [XHR2] ArrayBuffer support added
On Fri, 04 Mar 2011 01:45:08 +0100, Charles Pritchard wrote: Following up on this older thread, Mozilla has added ArrayBuffer to their XHR object, though the documentation is a little bare. xhr.mozResponseArrayBuffer That feature is already in the draft via responseType/response. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer support added
Following up on this older thread, Mozilla has added ArrayBuffer to their XHR object, though the documentation is a little bare. xhr.mozResponseArrayBuffer On 2/4/2011 2:01 AM, Anne van Kesteren wrote: On Thu, 03 Feb 2011 23:56:13 +0100, Charles Pritchard wrote: But in the present, we've got XMLHttpRequest, with CORS semantics, and all other manner of goodness. EventSource seems to me, to have different use cases than the simpler XHR. Yes, it is meant for streaming. XMLHttpRequest isn't really. (And EventSource will get CORS in due course.) XHR is a pretty stable and well supported method, it seems that it'd be reasonably straightforward to take the current good-will around that standard, and see if a second ArrayBuffer response type is warranted. I rather wait until all the new features are more widely adopted and tested. Then we can see if they have been a success and if we need more. One nice thing to come out of it, saving a large file to a disk via XHR and FileWriter would be made much easier, with no need for temporary storage locations. Even with blob saved to disk, it'd take a lot of special case optimizations to make it efficient to copy that Blob to a new file. It'd likely require a copy, instead of what's likely wanted: writing the file once. Developing this now could have a positive effect on a future EventSource standard.
Re: [XHR2] ArrayBuffer support added
On Thu, 03 Feb 2011 23:56:13 +0100, Charles Pritchard wrote: But in the present, we've got XMLHttpRequest, with CORS semantics, and all other manner of goodness. EventSource seems to me, to have different use cases than the simpler XHR. Yes, it is meant for streaming. XMLHttpRequest isn't really. (And EventSource will get CORS in due course.) XHR is a pretty stable and well supported method, it seems that it'd be reasonably straightforward to take the current good-will around that standard, and see if a second ArrayBuffer response type is warranted. I rather wait until all the new features are more widely adopted and tested. Then we can see if they have been a success and if we need more. One nice thing to come out of it, saving a large file to a disk via XHR and FileWriter would be made much easier, with no need for temporary storage locations. Even with blob saved to disk, it'd take a lot of special case optimizations to make it efficient to copy that Blob to a new file. It'd likely require a copy, instead of what's likely wanted: writing the file once. Developing this now could have a positive effect on a future EventSource standard. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer support added
On 2/1/2011 6:05 AM, Anne van Kesteren wrote: On Tue, 01 Feb 2011 14:58:02 +0100, ATSUSHI TAKAYAMA wrote: (I didn't send the previous mail to the list, so sending again) I hope we can actually just do this by exposing "blob" earlier than DONE in due course. With the Blob object on disk growing over time. If you really just want to stream data I think we should use EventSource for that. IMHO, EventSource is too cumbersome to handle binaries as you have to special-case both CR and LF, and CRLF sequence. That it does not deal with raw octet-data now does not mean it will not in the future. But in the present, we've got XMLHttpRequest, with CORS semantics, and all other manner of goodness. EventSource seems to me, to have different use cases than the simpler XHR. XHR is a pretty stable and well supported method, it seems that it'd be reasonably straightforward to take the current good-will around that standard, and see if a second ArrayBuffer response type is warranted. One nice thing to come out of it, saving a large file to a disk via XHR and FileWriter would be made much easier, with no need for temporary storage locations. Even with blob saved to disk, it'd take a lot of special case optimizations to make it efficient to copy that Blob to a new file. It'd likely require a copy, instead of what's likely wanted: writing the file once. Developing this now could have a positive effect on a future EventSource standard. -Charles
Re: [XHR2] ArrayBuffer support added
On Tue, 01 Feb 2011 14:58:02 +0100, ATSUSHI TAKAYAMA wrote: (I didn't send the previous mail to the list, so sending again) I hope we can actually just do this by exposing "blob" earlier than DONE in due course. With the Blob object on disk growing over time. If you really just want to stream data I think we should use EventSource for that. IMHO, EventSource is too cumbersome to handle binaries as you have to special-case both CR and LF, and CRLF sequence. That it does not deal with raw octet-data now does not mean it will not in the future. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer support added
(I didn't send the previous mail to the list, so sending again) > I hope we can actually just do this by exposing "blob" earlier than DONE in > due course. With the Blob object on disk growing over time. If you really > just want to stream data I think we should use EventSource for that. IMHO, EventSource is too cumbersome to handle binaries as you have to special-case both CR and LF, and CRLF sequence. A.TAKAYAMA
Re: [XHR2] ArrayBuffer support added
On Mon, 31 Jan 2011 18:27:51 +0100, Charles Pritchard wrote: While on that topic, it'd be nice to see a fixed-size ArrayBuffer, for working with streams and large-files. Currently: blob requires the entire file be downloaded before use, classically, the stream could be ready while downloading, and the final response just 'tossed' (when the stream is complete). Even a hard-coded array buffer size would be helpful (though it'd be nice to have that as a settable value): Something along these lines would allow processing of binary data without requiring the entire stream to be loaded into memory / downloaded. xhr.responseType='stream' xhr.buffer = new ArrayBuffer(...len...); I hope we can actually just do this by exposing "blob" earlier than DONE in due course. With the Blob object on disk growing over time. If you really just want to stream data I think we should use EventSource for that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer support added
On Mon, 31 Jan 2011 10:17:23 +0100, Anne van Kesteren wrote: I somehow missed that a request to add back ArrayBuffer support was offlist. Since quite a few specifications are using it now and TC 39 has shown no progress on developing an alternative I was convinced to add it back in. The responseType value is "arraybuffer". This adds a dependency to the Typed Array specification developed at Khronos. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ I summarized a bit unfairly towards TC 39. The expectation is that TC 39 does not move as fast as Khronos and that therefore ArrayBuffer will likely stick around. If it turns out it can be replaced XMLHttpRequest will just follow along of course. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer support added
On 1/31/2011 1:17 AM, Anne van Kesteren wrote: I somehow missed that a request to add back ArrayBuffer support was offlist. Since quite a few specifications are using it now and TC 39 has shown no progress on developing an alternative I was convinced to add it back in. The responseType value is "arraybuffer". This adds a dependency to the Typed Array specification developed at Khronos. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ While on that topic, it'd be nice to see a fixed-size ArrayBuffer, for working with streams and large-files. Currently: blob requires the entire file be downloaded before use, classically, the stream could be ready while downloading, and the final response just 'tossed' (when the stream is complete). Even a hard-coded array buffer size would be helpful (though it'd be nice to have that as a settable value): Something along these lines would allow processing of binary data without requiring the entire stream to be loaded into memory / downloaded. xhr.responseType='stream' xhr.buffer = new ArrayBuffer(...len...); -Charles
[XHR2] ArrayBuffer support added
I somehow missed that a request to add back ArrayBuffer support was offlist. Since quite a few specifications are using it now and TC 39 has shown no progress on developing an alternative I was convinced to add it back in. The responseType value is "arraybuffer". This adds a dependency to the Typed Array specification developed at Khronos. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ -- Anne van Kesteren http://annevankesteren.nl/
