Dave Bakker

@rvolosatovs Thanks for your feedback. I've been trying out different variations of your suggestions. Aside from some details, I think that overall they indeed yield a better solution. Would you...

> I didn't happen to catch this before the latest refactoring, though, so I don't know how different the API would look like to support arbitrary I/O sources. The current...

Yes, we definitely could. That being said, assuming a `pipe`-like construct exists, I quite like the current design as it is simpler while also being a more general-purpose solution that's...

Thinking about it some more, `forward` and `pipe` are probably equally powerful at the theoretical level. Yet, `forward` has the advantage of being usable on all existing stream sources. E.g....

I want to thank everyone for their contributions so far! Now that TLS is a separate proposal, we'll continue [over there](https://github.com/WebAssembly/wasi-tls). :rocket:

I completely understand the challenge you're facing and I can see why this change might seem like a straightforward improvement. That said, I do have some concerns about its broader...

Thanks for the detailed explanation (as usual :cowboy_hat_face:) Unless I'm mistaken, this protocol seems susceptible to infinite blocking in the presence of false wake-ups. If one side of the stream...

As an optimization, the CM could additionally offer `stream.try-read` & `stream.try-write` built-ins. They would both take the same parameters and return the same types as the non-try variants, but with...

> Good idea! As a small tweak to consider, we could also add `try` as an alternative immediate to `async` in the existing `{stream,future}.{read,write}` built-ins Fine by me :+1: Maybe...

Just for cross-referencing: A similar issue was raised [here](https://github.com/WebAssembly/wasi-sockets/pull/104/files#diff-a36be87127e6a8bf8f8f1d184f1b13c47309e164d1f67337e8898f5aea30f2d3) regarding the `protocol-version` type.