Re: [XHR] support for streaming data

On 8/8/2011 5:13 PM, Jonas Sicking wrote:
> Hi All,
>
> XHR Level 2 does wonders for making XMLHttpRequest better. However
> there is one problem that we have run into with "streaming" data.
...
Agreed. I proposed something similar in January, with fixed buffer lengths:
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0304.html

Fixed buffers are somewhat common with more data intense network processing.
They may trigger quite a few more progress events, but they guarantee an 
upper
size in memory usage / array length.
...
> Same thing when .responseType is set to "streaming-arraybuffer". In
> this case .response is set to an ArrayBuffer containing the data
> received since the last "progress" event.
>
> There is one non-ideal thing with this solution. Once the last chunk
> of data has arrived, at least Firefox doesn't fire a "progress" event,
> but instead just a "load" event. This means that people will have to
> consume data both from the "progress" event and from the "load" event.
>
> Another solution would to make sure to always fire a "progress" event
> for the last data before firing the "load" event. I personally like
> this approach more. There *might* even be reasons to do that to ensure
> that pages create progress bars that reliably reach 100% etc.
>
I agree to this, too. For a stream, load may be the same thing as stop, 
and not have result data.

Anne suggested using EventSource and other WebSockets style semantics 
instead of overloading
XHR2.
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0314.html
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0375.html

I'd be happy-enough just having a streaming binary buffer.

-Charles

Received on Tuesday, 9 August 2011 00:48:47 UTC