Async I2C

[sunfishcode]

The current wasi-i2c interface here is entirely synchronous. That's a good place to start, but there are also a lot of use cases that need an async API, so it'd be interesting to start collecting ideas about what we might want this to look like.

Explicit async: I sketched a possible async-i2c interface here. It could be used directly, or from any async runtime built to run on wasi-io polling, such as eg. @yoshuawuyts's wasi-async-runtime, which is a lightweight async runtime that would enable writing convenient async applications in Rust. A downside of this approach is that it's effectively a whole parallel Wit API to the sync API, but an upside is that it could be implemented with current tools.

Integrated async: As another possible approach, we could just wait for the expected component-model integrated async to be usable. This has been talked about here and prototyped here, and there is now work going on towards proposing it to the component-model spec and implementing it in major tools. A downside of this approach is that it's not implemented in current tools yet, but a major upside is that a single Wit description can describe both both a sync and async API. Caller and callee can each independently chose if they want to be sync or async, and they can be linked (watch the talk I linked earlier to see how this works).

So perhaps if there's a need an async API in the short term, maybe we could go with the explicit async option for now, but otherwise perhaps we should wait for integrated async.

[merlijn-sebrechts]

We lean towards waiting for broader async support in component model. During our discussions with the co-champions, we didn't see an immediate need for async support. Given the ecosystem is still in flux about that, we deemed it best to wait.

A purely synchronous implementation would provide a lot of value on its own, so we were planning on moving the proposal forward like that.

[sunfishcode]

Makes sense, thanks!