Wit - documentation/examples for multiple export/imports

[artiemq]

Hi! I’m exploring WASI and WIT and have some questions about it. I'd appreciate any clarifications

1. Can I import multiple components of the same interface into a single WebAssembly component?
For example, during a migration from one message queue (MQ) system to another, is it possible to import two message queue libraries of the same type (interface) (e.g., one for the old provider and one for the new) into the same component?

2. Is it possible for a WebAssembly component to export multiple components of the same type?
For exmple, during a MQ migration, could I export two message queue providers (one for each provider) from a single module?

3. Is there support for importing an array of components in WIT?
For example, could I import an array of middleware components for an HTTP service component?

4. Can a component export an array of components?
Similarly, is it possible to export an array of components, like an array of HTTP handlers?

5. How can I store data within a component itself?
It seems like components are designed to contain only logic. If that’s true, how would I implement something like an in-memory cache inside a component? Is there a mechanism to persist state or data within the component itself?
For example static configuration for some business logic

I couldn’t find any examples beyond the basic cases, but these seem like essential features for many applications, so there should be a way to make them work

---

I have a few more questions about wit-bindgen. I realize this might not be the best repo for these questions, but I’d be grateful if you could provide some clarifications

6. Why are some functionalities provided through bindings while others are built into languages standard features?
For example, why is printing to stdout available via the standard println!() macro, while other features (e.g., wasi:sql.readwrite/query) require bindings?

7. Why are Rust (and other languages) bindings provided as regular functions rather than traits with implementations?
The current approach makes it challenging to test components without introducing additional abstraction layers.