- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 8 Aug 2011 17:59:07 -0700
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Webapps WG <public-webapps@w3.org>
On Mon, Aug 8, 2011 at 5:48 PM, Charles Pritchard <chuck@jumis.com> wrote: > 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. Unless EventSource is dramatically changed, it won't solve the use cases here. One use case that I've brought up several times in the past is incremental loading of Word documents. A more current example would be loading a pdf document and rendering it incrementally as data is coming in. Neither of these cases is even close to how EventSource currently works, so I don't think it's a good fit. / Jonas
Received on Tuesday, 9 August 2011 01:00:04 UTC