Structure WASI APIs

[abbec]

The WASI APIs that we add need to be structured into different pieces. The pieces that can be implemented outside Avery should be implemented as a separate library and then the symbols are just exported in Avery or any other host. This would allow other hosts to use these APIs, for example an alternative Python executable. In that case, the wasi Python shims that we have should assume that something will provide the symbols needed to implement things like sockets, threads, etc.

The pieces that can only be implemented inside Avery should of course be implemented there but be part of a separate import/export namespace. This is for example support functions for node graphs (allocating streams, setting connections, queueing function execution etc.).

[abbec]

Actually, this should even be implemented without ties to WASI:

• A library that handles all the host-side functionality of Firm
• The library is exposed through the Avery runtimes to WASI etc.

This also makes it easier to support multiple WASI runtimes.

[abbec]

This has a JIRA issue now.