Define streams common operations in Infrastracture section. #54
Conversation
|
|
||
| A __ReadableStream__ represents a stream of data, as specified in https://streams.spec.whatwg.org. In this section, we define common operations for ReadableStream used in this spec. | ||
|
|
||
| There are two kinds of signals, __pull__ and __cancel__. They can be signalled to a ReadableStream. |
There was a problem hiding this comment.
Nowhere. I wanted a kind of event dispatching without DOMEvent complexity (Event interface, bubbling, multiple listeners, ...). I thought "signal" was simple enough like "terminate" used in the fetch spec.
Do you know a defined word suited with such use-case?
There was a problem hiding this comment.
Maybe it's okay for now. I don't really have a better alternative. Other than maybe callback algorithm or some such... (Ideally "terminate" would be defined from first principles too.)
There was a problem hiding this comment.
I think this can be rephrased to be a bit simpler. I would remove all of this about signals, then define "To construct a ReadableStream with given strategy, pull action, and cancel action, run these steps."
There was a problem hiding this comment.
Sounds nice. As we don't need pull signal in "need more data" definition any more, we can replace signals with actions. Done.
|
So, this over all looks pretty reasonable, but it doesn't actually address the biggest part of #52, which is IDL vs. JS values. Each defined algorithm probably needs a step at the beginning converting inputs into JS values and a step at the end converting outputs into IDL values. (Or, a blanket "in these steps we conflate IDL and JS values" disclaimer.) |
|
In #50 and #52 some solutions were proposed and we didn't choose one. I would like to collect JS-stream related definitions in one place so that we can deal with the problem easily in the future (i.e. I won't close #52 after this PR is landed, but add "not-included-in-the-first-release" label to it and start creating merge PRs). I can add "we don't distinguish JS-stream and IDL-stream as of now" note in this PR. |
|
@domenic, are you fine with this change? |
| 1. Let _promise_ be a new promise. | ||
| 1. Let _bytes_ be an empty byte sequence. | ||
| 1. Let _read_ be the result of calling [ReadFromReadableStreamReader(_reader_)]. | ||
| 1. When _read_ is resolved with an object whose `done` property is __false__ and whose `value` property is a Uint8Array, append the `value` property to _bytes_ and run the above step again. |
There was a problem hiding this comment.
s/resolved/fulfilled here and in the next two steps.
|
Yes, LGTM with some minor comments. Good stuff. |
This is a refactoring effort. Addressing #52.
yutakahirano
force-pushed
the
infrastructure-refactoring
branch
from
0408752 to
f4354e5
Compare
|
Thank you! |
Define streams common operations in Infrastracture section.
This is a refactoring effort. Addressing #52.