001: initial C++ Streams proposal

[indutny]

cc @trevnorris

[trevnorris]

/cc @bnoordhuis @rvagg Think your feedback would be valuable here as well.

[trevnorris]

Consider doing this how is done in LEPS (https://raw.githubusercontent.com/libuv/leps/master/001-remove-unix-support.md). As this is now all these entries will be placed on the same line.

[indutny]

Like this?

[trevnorris]

Can we include a helper function or whatnot for recalculating the uv_buf_t**? We have the logic already in StreamWrap::DoTryWrite(), and it'd be a shame for everyone to need to implement basically the exact same on their own.

[chrisdickinson]

This might not be in-scope for this NEP, but one of the more interesting attributes of WHATWG streams is the ability to do brand-checking during readable.pipe(writable) and skip a round trip into JS if both the readable and writable sides can communicate at the C++ layer. It'd be interesting to expose this functionality through the public stream implementation — so that if a non-handle-backed Stream were piped to a handle-backed stream, things would still work, but if two handle-backed streams were .pipe()'d together, they could communicate directly.

[indutny]

Sorry for delay, I took it to consider things more carefully. Turns out, I agree with @bnoordhuis , adding this won't really create more value than problems. Let's close this for now.

Thank you for your time, and sorry for wasting it on this. 😞

[trevnorris]

@indutny :( The concept was good. Hopefully we can figure out how to get something like this into core in the future.

[indutny]

We have this in core already :) I'm not suggesting to remove it, just don't think that making it public would be beneficial.

[trevnorris]

Sorry. should have read "as public API in core"

[trevnorris]

Forgot that even rejected proposals are still merged. Landed in 9faa231.

[mcollina]

What's the status of this proposal in core? Was it exposed?

[indutny]

I believe the proposal was rejected. The APIs are not exposed.