W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [XHR] support for streaming data

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 8 Aug 2011 17:59:07 -0700
Message-ID: <CA+c2ei8NfwdF9=hgf+cowy=qtXA+cpHYw21Xd-OMofTigP=hFQ@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT