Should blocking functions be enhanced or removed?

[alexcrichton]

I wanted to log a discussion I had with some folks recently (cc @lukewagner, @sunfishcode, @pchickey, @elliottt) where we were talking about the blocking-* family of functions present on the streams interface.

Attempting to summarize the discussion, my impression was that the functions were originally added for convenience for examples/tutorials/getting started/etc, but with the recent developments around writes and flush happening on bytecodealliance/wasmtime#6877 the story there was a bit more unclear and a blocking-write function is less obvious than before.

One option was to enhance/updated the blocking-* functions to do "what you might expect" e.g. bundling a check-write or things like that. The other option though was to go the other way and remove the convenience blocking-* functions for now and optionally add them back in later.

We figured that no changes should probably be done in the preview2 time frame but we would want to consider changes for a later time frame.

[pchickey]

I believe we should leave whatever blocking- family functions in that are convenient for users for preview2. For preview3, we expect all of this to go away and be replaced by component model primitives. So, there isn't much we should plan to change here.

[sunfishcode]

This has been addressed by #45 and #53. We now have a set of blocking functions which provide a simple API for blocking use cases, including a check-write mechanism.