RE: [XHR]

From: Gomer Thomas [mailto:gomer@gomert-consulting.com]


>               [GT] It would be good to say this in the specification, and reference
> some sample source APIs. (This is an example of what I meant when I said it
> is very difficult to read the specification unless one already knows how it is
> supposed to work.)

Hmm, I think that is pretty clear in https://streams.spec.whatwg.org/#intro. Do you have any ideas on how to make it clearer?

>               [GT] I did follow the link before I sent in my questions. In section 2.5 it
> says "The queuing strategy assigns a size to each chunk, and compares the
> total size of all chunks in the queue to a specified number, known as the high
> water mark. The resulting difference, high water mark minus total size, is
> used to determine the desired size to fill the stream’s queue." It appears
> that this is incorrect. It does not seem to jibe with the default value and the
> examples. As far as I can tell from the default value and the examples, the
> high water mark is not the total size of all chunks in the queue. It is the
> number of chunks in the queue.

It is both, because in these cases "size" is measured to be 1 for all chunks by default. If you supply a different definition of size, by passing a size() method, as Fetch implementations do, then you will get a difference.

>        [GT] My original question was directed at how an application can issue an
> XMLHttpRequest() call and retrieve the results piecewise as they arrive,
> rather than waiting for the entire response to arrive. It looks like Streams
> might meet this need, but It would take quite a lot of study to figure out how
> to make this solution work, and the actual code would be pretty complex. I
> would also not be able to use this approach as a mature technology in a
> cross-browser environment for quite a while -- years? I think we will need to
> implement a non-standard solution based on WebSocket messages for now.
> We can then revisit the issue later. Thanks again for your help.

Well, you can be the judge of how complex. https://fetch.spec.whatwg.org/#fetch-api, https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html, and https://jakearchibald.com/2016/streams-ftw/ can give you some more help and examples.

I agree that it might be a while for this to arrive cross-browser. I know it's in active development in WebKit, and Mozilla was hoping to begin work soon, but indeed for today's apps you're probably better off with a custom solution based on web sockets, if you control the server as well as the client.

Received on Thursday, 17 March 2016 19:47:05 UTC