Should this crate use the `wasi` crate?

[lann]

I haven't validated that this is actually plausible, but if it is it would have advantages:

• It would allow better compatibility with other libraries that use the wasi crate.
• We wouldn't have to generate (most) wasi bindings any more.
• We (probably) wouldn't have to keep wasi WIT in-tree any more.

[vdice]

I'd just like to say this is a crate idea

[rylev]

This ultimately sounds like a good idea. However, I think currently it's not really possible as we add a few trait implementations for wasi types (e.g., std::error::Error for io::streams::Error) which we cannot do if the types originate from some downstream crate. I imagine we'll probably want to upstream support for adding common trait implementations to types before we consider using the crate here.

[lann]

bytecodealliance/wasi-rs#85

[radu-matei]

With ^^ merged, does that mean we could use the WASI crate instead?

[rylev]

It gets us closer (here's a branch with the latest: https://github.com/fermyon/spin-rust-sdk/compare/use-wasi-crate).

What's left:

• We add several functions and a few trait implementations to wasi defined types which we're allowed to do when those types are defined in the crate but which we will no longer be able to do. We'd have to find a substitute for that such as using extension traits or new types. It's not clear which solution is the best.
• The handler macro is still using types we define ourselves. I think we will be able to move to using the wasi trait without issue, but I just haven't done it yet.