-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
WASI: asynchronous name resolution APIs #73
Comments
Following up on my coment in #69, my impression is that the best way to go here might be to start thinking in terms of creating a Network module, separate from the Core module. Core can just focus on relatively generic stream/datagram operations, and Network can be the place where we do DNS, create sockets, and so on. If that makes sense, it'd be good to start making a rough list of features that the Network module should aim to include. |
I think that's sane. Regarding DNS, we can also choose not to offer APIs. We can just depend on libraries to do this lifting for us. But if we do provide name resolution, it need to be async. Honestly, I'd love to see a SOCK_DNS socket type for name resolution. You push a struct into the socket and poll() to wait for the reply. However, and I'm afraid I might be harping on this, I'd really like to keep the core module very small. With versioning (#74), we can always expand it and even break the ABI. But, IMHO, core should only be a set of ABIs that all other modules depend on. I don't think there is any requirement for core to be functional by itself. |
…odealliance#73) * Split wasi-stream into separate input and output stream types. This syncs the prototype's streams with the upstream wasi-io repo. Streams are unidirectional, so this allows us to statically describe whether something is an input stream or an output stream in an interface. This differs a little from the component model async streams, which don't have separate input and output streams, but it does partially reflect how the component model async design differentiates between input streams in type signatures, which are passed in as arguments, and output streams, which are returned as return values. * Fix compilation on Windows.
…odealliance#73) * Split wasi-stream into separate input and output stream types. This syncs the prototype's streams with the upstream wasi-io repo. Streams are unidirectional, so this allows us to statically describe whether something is an input stream or an output stream in an interface. This differs a little from the component model async streams, which don't have separate input and output streams, but it does partially reflect how the component model async design differentiates between input streams in type signatures, which are passed in as arguments, and output streams, which are returned as return values. * Fix compilation on Windows.
wasi-sockets has an asynchronous resolver . The interface itself is pretty simple and leaves it up to the implementation to pick the most appropriate resolver strategy. (Hostfile, DNS, DNS-over-HTTPS, ...) Anyway, I think this issue can be closed now. Any further discussion (if any) can take place at https://github.com/WebAssembly/wasi-sockets |
…am-2 Merge upstream
Weekly merge with upstream
One of the greatest flaws of current *nix APIs is its complete lack of async DNS. We also need native support for encrypted DNS. This should be one of the highest priorities on the "things to fix" list.
The text was updated successfully, but these errors were encountered: