Re: [XHR] support for streaming data

On 8/8/11 5:13 PM, Jonas Sicking wrote:
> To solve this I propose we add two new values to .responseType:
> "streaming-text" and "streaming-arraybuffer".
I think this would be a very useful feature.  I only have naming nits:

1) What do you think of "textstream" instead of "streaming-text"?  
Similarly for arraybufferstream (or ArrayBufferStream)

2) Is there any possible use case for streaming blobs?  If so, then I'd 
say that the streaming vs. non-streaming issue is orthogonal to the data 
type issue and there should be something like responseMethod = "stream" 
instead of responseType = "streaming-text"

3) What you propose isn't exactly what I think of as streaming, since 
there isn't a FIFO buffer involved.  I can't get a progress event, read 
a few bytes of the response and then leave the rest to process at the 
load event, can I?  In this proposal we get one chunk of data per 
progress event, and that data will be gone when the next progress event 
arrives, right?  Would names like "ChunkedText" and "ChunkedArrayBuffer" 
more accurately reflect what is going on?  Or, if "Chunked" would 
incorrectly imply some relationship to HTTP chunked encoding, how about 
"TextFragments" and "ArrayBufferFragments"

> When .responseType is set to "streaming-text" then during each
> "progress" event, .response would be set to the text that was received
> since the last "progress" event (and since the "loadstart" event for
> the first "progress" event).
>
> 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.

It seems like it would be important for browsers to do that for these 
responseTypes, even if they didn't do it for regular "text" and 
"arraybuffer" responses.
> / Jonas
>
     David

Received on Tuesday, 9 August 2011 04:36:50 UTC