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

Reply via email to