Yeah, thinking of it a bit more carefully, we would need to define a Standard Stream Interface in order to have the 3 Standard IO Streams. I can start putting together some research and a sample interface to present my ideas in more depth, but it'll take some time to flesh everything out. But we can still start hashing out some ideas in the meantime, and making sure concerns are addressed.
I believe we should define both an synchronous and asynchronous API day one, where the "normal" reads would be blocking and return the value, if the "normal" writes are blocking or not would be host environment specific, and the asynchronous versions of both would return promises. So if there is a read/write, there would also be a readAsync/writeAsync. Another option instead of doubling up all the functions for a single Stream Object, is to define both a Stream and Async Stream Object, and have a method to get the other kind from in both. So a normal synchronous Stream could have an Async() method to get the Async Stream version, and the Async version can have a Sync() method to get the normal Stream version. The easy out for how to deal with queueing and back pressure is that it is implementation details of the host environment. Ideally a user would be able to use both the synchronous and asynchronous functions on a Stream, even if the Host Environment only actually supports one kind. But I don't think it’s our place to solve for a user trying to write 100GB of data asynchronously or read a 100GB of data synchronously. I believe what we can do is define a Standard Exception that can be thrown if the buffers overflow, let the host environment define how large their buffers are, and maybe give them the option of throwing out data if desired (Maybe for some hypothetical host environment in the future, the Standard Error's Buffer overflowing and losing data is acceptable behavior and does not need to raise an exception) One thing to note, just because the language defines standard Streams, does not mean we necessarily have to define how a user can create their own Streams at this time. The day one version could make Streams only something setup by host environment. Host Environments that don't want to support a standard in could have an object that just throws an exception if a user tries to output any data, and those that don't want to support a standard out/error could have the functions stubbed out. So, some things that come to mind also, should these Streams only support text data, or should they be usable for binary data too? And should there be a single Base Stream class, or should the Input Stream and Output Stream be different things (If they are a single base class, a function could be added to allow for code to check the Stream Type). I think for the first passes, generators and async iteration don’t need to be considered, and can be taken into account for once it starts taking shape. From: Michael J. Ryan <track...@gmail.com> Sent: Sunday, April 29, 2018 3:47 PM To: Chet Michals <chetmich...@gmail.com> Cc: es-discuss <es-discuss@mozilla.org> Subject: Re: Suggestion: Add Standard IO Streams Why not create an npm module that represents what you'd like to see as an interface wrapping node's implementation and propose your new interface? This way you can try building something with it. You'll first need to implement how you see a synchronous stream in the first place. Streams can be a complex beast though. Do you want a synchronous or asynchronous implementation or both? Will they consume like generators, async iteration (for await of)? What about queueing and back pressure? On Sat, Apr 28, 2018, 22:28 Chet Michals <chetmich...@gmail.com <mailto:chetmich...@gmail.com> > wrote: Working between a number of different ECMAScript environments over the years, such as in Java with Rhino and Nashorn, Node.js, and various web browsers, one thing I have noticed is that there is no standard input/output/error stream like most other languages support, and each ecosystem tends to define their own host objects to deal with these, like the console object in most Web Browsers (Which is at least defined in a WHATWG Living Standard), the process object in Node.js, and the print object in Nashorn. I feel for long term portability, the 3 standard IO streams should be added to the spec in some way, Is there a reason I am not seeing as to why this wouldn't be desired? _______________________________________________ es-discuss mailing list es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
