[html5] "internal slot"

[Domenic Denicola]

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


>               In the particular application I have in mind the stream of data comes
> from a remote server over a WebSocket connection. There is no possibility of
> back pressure. The chunks of bytes are simply pushed asynchronously. The
> client Javascript code sends a request for the byte stream to start, and the
> bytes start arriving.

Hopefully https://streams.spec.whatwg.org/#example-rs-push-no-backpressure gives you some idea of how you could accomplish that.

There are vague plans to eventually introduce a backpressure-supporting ReadableStream interface for web sockets. However, we may not need to do this at all, since the primary benefits of web sockets (duplex streaming) is available with just normal HTTP/2. See previous discussions at:

- https://www.w3.org/Bugs/Public/show_bug.cgi?id=23992
- https://github.com/whatwg/fetch/issues/229

>               I think a good part of my confusion stems from my assumption that
> part of the "Streams" machinery (implementations of some of the
> Classes) is intended to be built into off-the-shelf user agents, and part
> (implementation of other Classes) must be provided by Javascript code. I am
> having trouble understanding which Classes fall into each category.

Hmm, interesting feedback. All of the classes in the spec are provided by the browser. The "underlying source" object is provided by JavaScript code, but it's not a class in the spec, it's just an argument.

>        By the way, one thing that would make the specification more
> understandable to a reader would be to make it explicit that the
> ReadableStream is what makes the underlyingSource.start(controller) and
> underlyingSource.pull(controller) calls, and to make explicit the connection
> between the "controller" argument passed in those calls and the value of the
> [[readableStreamController]] slot. The informative text says that the
> "controller" can be a ReadableByteStreamController or a
> ReadableStreamDefaultController, and the constructor steps describe how
> to set the slot value to one or the other of these, but I could not find
> anything that says the "controller" argument passed in the start() and
> pull() calls is the slot value. This just seems to be implicitly assumed -- OK if
> the reader already knows what is going on, but not so good if the reader is
> trying to understand what is going on.

I don't think this is very important knowledge for JavaScript developers; it's only relevant to implementers. That is because internal slots are only relevant to implementers. And for them, it's stated very explicitly in the spec's algorithms.

>        Another quick question: One of the "Conventions" in the Streams
> document is " We similarly use the default argument notation = {} in a couple
> of cases." What does that mean? When that appears, what is being defined
> as a default for what?

I agree that this is not as clear as it could be; I am hoping to clear up some of the conventions soon, especially to match recent updates to the JS spec. The idea is that a new empty object is used as a default for the argument. So instead of defining:

getReader(options)

1. If options is undefined, let options be ObjectCreate(%ObjectPrototype%).
2. ....

We just define

getReader(options = {})

1. ...