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
