Thanks for the suggestion.
I looked at the Streams specification, and it seems pretty immature and
underspecified. I’m not sure it is usable by someone who doesn’t already know
how it is supposed to work before reading the specification. How many of the
major web browsers are supporting it?
For example:
(1) The constructor of the ReadableStream object is “defined” by
Constructor (underlyingSource = { }, {size, highWaterMark = 1 } = { } )
The “specification” states that the underlyingSource object “can” implement
various methods, but it does not say anything about how to create or identify a
particular underlyingSource. In my case I want to receive a stream from a
remote HTTP server. What do I put in for the underlyingSource? What does the
underlyingSource on the remote server need to do? Also, what does the
“highWaterMark” parameter mean? The “specification” says it is part of the
queuing strategy object, but it does not say what it does. Is it the maximum
number of bytes of unread data in the Stream? If so, it should say so. If the
“size” parameter is omitted, is the underlyingSource free to send chunks of any
size, including variable sizes?
(2) The ReadableStream class has a “getReader()” method, but the
specification gives no hint as to the data type that this method returns. I
suspect that it is an object of the ReadableStreamReader class, but if so it
would be nice if the “specification” said so.
Regards, Gomer
--
Gomer Thomas Consulting, LLC
9810 132nd St NE
Arlington, WA 98223
Cell: 425-309-9933
From: Jonathan Garbee [mailto:jonathan.gar...@gmail.com]
Sent: Wednesday, March 16, 2016 5:10 AM
To: Hallvord Reiar Michaelsen Steen <hst...@mozilla.com>; Gomer Thomas
<go...@gomert-consulting.com>
Cc: WebApps WG <public-webapps@w3.org>
Subject: Re: [XHR]
If I understand correctly, streams [1] with fetch should solve this use-case.
[1] https://streams.spec.whatwg.org/
On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen
<hst...@mozilla.com <mailto:hst...@mozilla.com> > wrote:
On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas
<go...@gomert-consulting.com <mailto:go...@gomert-consulting.com> > wrote:
> According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the
> chunked transfer coding”. The logical interpretation of this is that
> whenever possible HTTP recipients should deliver the chunks to the
> application as they are received, rather than waiting for the entire
> response to be received before delivering anything.
>
> In the latest version this can only be done for “text” responses. For any
> other type of response, the “response” attribute returns “null” until the
> transmission is completed.
How would you parse for example an incomplete JSON source to expose an
object? Or incomplete XML markup to create a document? Exposing
partial responses for text makes sense - for other types of data
perhaps not so much.
-Hallvord
