Dave Bakker

> do you think we should keep the at_ APIs? Or is this change specific to 0.2.x, and we should actually remove the at_ APIs in 0.3? Even for 0.3+,...

That's correct. The current WASI `open-at` is most similar to Linux' `openat2` with `RESOLVE_BENEATH`. To get POSIX `openat` behavior with my POC, is for wasi-libc to prepend the path of...

Ah right. The devil is always in the details. Do you have any ideas on how to go about this in such a way that it can be implemented efficiently...

Hi, thank you for reaching out! IIUC: - you want to incorporate WASM into the Istio/Envoy sidecar itself, and your goal is not to WASM'ify the main application workload. -...

Hmm. In that case, I don't understand why you would need ORIGINAL_DST from within WASI at all. Istio takes on the role of the application WASM runtime. The host implementation...

@keithmattix Was my answer of any help? Let me know if there's anything else you'd like discussing on this topic.

Thanks for summarizing and opening this issue! IIRC, this discussion was sparked when going over the socket options specifically. POSIX is pretty ambiguous about these, indeed. > define a set...

I think https://github.com/WebAssembly/wasi-sockets/pull/40 provides a good enough baseline to determine which socket options require further consideration. (Note: [the table](https://github.com/badeend/wasi-sockets/blob/document-posix-compatibility/Posix-compatibility.md) is horizontally scrollable). Does this take away your concerns?

It's hard to qualify the acceptable overhead. This differs on a function-by-function basis. Eg. `bind` is typically only called a few times per application lifetime, whereas `write` is called repeatedly....

I believe there are a couple of related, but separate issues here: --- > IPv6 support shouldn't be optional I assume you specifically mean that the `create-tcp/udp-socket` WASI functions should...