I am exploring using the new implements (aka "named imports") feature in a host. I have it working nicely with APIs that we control, but I have hit rocks with wasi:http (and will have the same problem with other WASI APIs). This happens because we use wasmtime-wasi and wasmtime-wasi-http for handling the WASI interfaces.
The trouble is that when, in my wasmtime::component::bindgen, I specify named_imports: { "wasi:http/handler@0.3.0": SomeKey }, this creates new Host* traits, with new types under the named_imports module. Not only is implementing all these host traits by hand is a chore, but it's laborious getting them to interoperate with wasmtime-wasi-http (and therefore with the rest of our HTTP configuration and stack), because they use different, newly bindgenned types, for things like Request and Fields and so on.
I am guessing it would be a lot less effort (and a lot less complexity) to modify wasmtime-wasi and wasmtime-wasi-http to handle implements of their underlying interfaces, but I'm not sufficiently familiar with the internals of these crates to tackle this myself or even offer a design suggestion. But I'm happy to provide more context or to try to dig in if that would be useful!
I am exploring using the new
implements(aka "named imports") feature in a host. I have it working nicely with APIs that we control, but I have hit rocks withwasi:http(and will have the same problem with other WASI APIs). This happens because we usewasmtime-wasiandwasmtime-wasi-httpfor handling the WASI interfaces.The trouble is that when, in my
wasmtime::component::bindgen, I specifynamed_imports: { "wasi:http/handler@0.3.0": SomeKey }, this creates newHost*traits, with new types under thenamed_importsmodule. Not only is implementing all these host traits by hand is a chore, but it's laborious getting them to interoperate withwasmtime-wasi-http(and therefore with the rest of our HTTP configuration and stack), because they use different, newly bindgenned types, for things likeRequestandFieldsand so on.I am guessing it would be a lot less effort (and a lot less complexity) to modify
wasmtime-wasiandwasmtime-wasi-httpto handleimplementsof their underlying interfaces, but I'm not sufficiently familiar with the internals of these crates to tackle this myself or even offer a design suggestion. But I'm happy to provide more context or to try to dig in if that would be useful!