WASI: Split networking into a module

[npmccallum]

Please make networking its own module.

[sunfishcode]

Currently there are only three networking-specific functions in WASI Core -- sock_send, sock_recv, and sock_shutdown. I have an idea for how we can merge sock_send and sock_recv with fd_write and fd_read (brief mention here), since they're very similar, and I believe would make the API more flexible and easier to understand.

If we do that, a possible path forward here is to also rename sock_shutdown to fd_shutdown and say that WASI Core doesn't have explicit networking support -- it just has support for reading, writing, and (partially) shutting down streams, which can either be byte-oriented or datagram-oriented (and may or may not have in-order delivery, etc.). These might be connected to TCP or UDP sockets, or they might be connected to UNIX-domain sockets, or perhaps even something like TLSSock, or other things. The WASI Core API would limit itself to generic stream/datagram functionality. Creating and configuring (bind, connect, accept, setsockopt, etc.) sockets, or accessing protocol-specific features (sendmsg, recvmsg, etc.), would be handled by a different API module.

What do you think of that approach?

[npmccallum]

I'm all for innovation. But first watch this talk: https://www.youtube.com/watch?v=za41nQ6Ein8 :)

I do think it makes sense to consolidate send()/write() and recv()/read(). However, there may be subtle differences. We should first learn why the fence is there.

In general, I'm strongly in favor of modularizing and versioning the APIs by integrating with the WASM module system (see #74). This means we aren't stuck with the bad decisions we make today.

[sunfishcode]

Yep :-). I've done some research and know quite a lot about why this particular fence is here, and even some of the accidental consequences it has. I'll write more about it when I make the actual proposal.

[sunfishcode]

Merging send/recv into read/write is now being tracked in WebAssembly/WASI#4.