Tight coupling between JS engine and browser engine

[KiChjang]

As it stands right now, the Fetch spec specifies that the bodies of both the Request and Response to have a ReadableStream object associated with it, which, if my spec reading is correct, is a JavaScript engine object, due to the existence of internal slots.

This overlaps the responsibilities of the JS engine and the browser engine - the JS engine depends on the browser engine to implement the Fetch spec, and the browser engine depends on the JS engine to implement the concept of a ReadableStream. I believe the ideal case would be to make it so that the fetch implementation is completely self-contained, i.e. only the browser engine should need to bear responsibility in handling network fetches.

[annevk]

Paging @yutakahirano and @domenic for thoughts. I'm not entirely sure this matters much. As long as what you implement is observably the same it does not really matter. I guess you're asking for some separation between "JS streams" and "IDL/internal streams", which the streams folks haven't been super interested in providing.

[domenic]

The Streams spec specifies itself in the style of ECMAScript, but makes no judgment as to whether you implement it in the JS engine or in the browser engine as long as the behavior is observably equivalent. In Chrome, we implement it in Blink, using a feature called V8 extras. We used to implement it in C++ using Blink's normal mechanisms.

[yutakahirano]

We are using promises which comes from ES6 in many APIs.

[annevk]

@domenic I think the concern is about defining user agent internal streams in terms of the Streams Standard. But I don't really see that being a big problem personally.

[annevk]

@KiChjang I'm inclined to close this. Any further thoughts on the matter?

[KiChjang]

It looks like my question has been answered; @domenic stated that it is up to the browser's implementation when it comes to process isolation. Thanks!