From: Gomer Thomas [mailto:go...@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.
