Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not conflate IDL ReadableStream and JS ReadableStream implicitly. #52

Closed
yutakahirano opened this issue Jul 31, 2015 · 4 comments
Closed

Comments

@yutakahirano
Copy link
Owner

Branched from #50.

We need to distinguish "fetch" (or "IDL") ReadableStream and "JavaScript" ReadableStream, and make their relationship clean.

@yutakahirano
Copy link
Owner Author

I think defining operations such as close and enqueue in the infrastructure section and using them from other parts are good for readability and modularity - We can say that we define IDL ReadableStream in the infrastructure section and we can move it to the WebIDL spec or the Streams spec later.
Even if we choose the first option of #50 (comment), handling ReadableStream as an IDL type in main fetch sections would be beneficial.

What do you think, @annevk, @domenic?

@annevk
Copy link

annevk commented Jul 31, 2015

Yeah, having it in the infrastructure temporarily makes sense.

@domenic
Copy link
Contributor

domenic commented Jul 31, 2015

I guess this makes sense if you prefer saying "enqueue idlChunk into idlReadableStream" instead of using EnqueueReadableStream directly on JS objects. It is probably a good refactoring.

@annevk
Copy link

annevk commented Jan 17, 2017

Maybe we should open an issue against IDL for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants