Phase 4 Advancement Criteria

[woodsmc]

Context. : Following on from the online-conversation on Advancement Criteria. The main advantage of this proposal is the ability to take legacy code and run it in WASI. @sunfishcode pointed out that POSIX support (as mentioned in the current proposal) is an ambiguous target and the real target was to be able to support legacy code. Therefore a more advantageous approach would be to define a set of example libraries or other software items which should be enabled by this WASI-socket's proposal, and add this to the list of Phase 4 Advancement Criteria.

The next challenge is to define what these libraries / software items are. It is important that such targets are not huge and don't contain a lot of additional other dependencies which may make it impossible to use as a test step.

The suggestions from the meeting notes included:

• Rust
• Python

Most legacy software is written in c/c++ so candidate software which uses the wasi-libc would be ideal. From this perspective, python would be more favorable.

[badeend]

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 of example libraries or other software items which should be enabled by this WASI-socket's proposal, and add this to the list of Phase 4 Advancement Criteria.

While they might be a good indicator of which socket options are commonly used in the wild, I don't want to tie the advancement criteria to any specific set of programming languages or applications. For example, Python was mentioned in the meeting; but even though Python has promoted a handful of socket options to be first class functions and properties, it still delegates the rest to a pretty thin wrapper around the native get/setsockopt. Regardless of which set of software we define as our baseline, we can never guarantee that any existing application will run fine without changes.

As for the advancement criteria, I think the desire is not to make any guarantees, but to document which POSIX/BSD/C/"native" functions and options were considered, which are included, what their WASI equivalent is, which are not included, why they're not included, etc.

[woodsmc]

This (below) would be awesome, and as presented I can see that a lot of research into this area has already been provided - which was amazing to see:

As for the advancement criteria, I think the desire is not to make any guarantees, but to document which POSIX/BSD/C/"native" functions and options were considered, which are included, what their WASI equivalent is, which are not included, why they're not included, etc.

I agree that (emphasis mine):

we can never guarantee that any existing application will run fine without change

But we should aim to avoid a situation where every existing application will need to be modified to run. If every application would need to be ported and it's impossible to create a BSD Sockets like interface, then the cost of adopting this proposal for anyone with an existing socket based application would be detrimentally high.

So this then begs the question... How can we assert that not every application needs significant modification to run? - The documentation would be useful, but it doesn't in and of itself provide a mechanism to assert this. As @sunfishcode suggested showing that there is enough in the proposal to support a popular library or open source software component would be one way of showing this. Anything which uses the BSD Socket interface and has rather broad usage across a number of platforms would be a possible candidate.

Python, Rust as languages, or maybe OpenSSL's libssl ? - It doesn't have to be a huge chunk of software, even a subset of it, e.g. libssl, working in a statically compiled WASI application would be amazing. Maybe even a simple hello world?

Regarding...

Python [...] still delegates the rest to a pretty thin wrapper around the native get/setsockopt.

A lot of existing code is going to use get/setsockopt, maybe a reference implementation is needed on a specific platform?

Is there any other approach?
I thought @sunfishcode's suggestion was fantastic. But I'm wondering, is there any other way we could assert / validate that ?

[badeend]

I think #40 provides a good enough baseline to determine which socket options require further consideration. (Note: the table is horizontally scrollable).

Does this take away your concerns?

[SoniEx2]

how much should it cost to translate between wasi-sockets and BSD sockets? (ideally, the equivalent of a table lookup?)

[badeend]

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. At the same time, write is more likely to be bottlenecked by IO than by the WASI<->BSD translation.

Other than: "It should be Reasonably efficient", I don't know how else to put it. Which is so vague and unenforcable, it might as well not be mentioned at all.

Suggestions?