[demo] Chicory advanced features

[andreaTP]

Follow up from this discussion with @andreas-karlsson .

This is not intended to be merged(I know nothing about the context and I have surely misinterpreted things ...), but it shows a couple of features of Chicory:

• in the first commit you have the switch to the build time compiler, here you have a comparison of the various execution modes, Tl;Dr: if you own and control the wasm payload(and versions) the fastest and most portable is the build time compiler(it will run on Android too! :-P)
• in the second commit I make use of the WasmModuleInterface annotation, it saves all the manual wiring(which, I guess, is the root cause of the desire to use MH), there is no magic, but is convenient, fast and gives a good feeling in the IDE. If you are in control of the ABI wasm/host it should help

[nicklasl]

The WasmModuleInterface annotation looks really cool, thanks for the tip!

[andreas-karlsson]

@andreaTP thanks! Yes, we should definitely make the switch to the build time compiler as we (currently, this might change) have the module at build time.

As for the WasmModuleInterface, yes that's a nicer way to define imports and call exports, what I'd like to do though (and I guess one often wants to) is to also implement the interop logic inside these export shims, like in our case consuming/transfering buffers and encoding/decoding protos. If I generate that code, I'm not sure if I gain anything by also basing it on this the in turn generated WasmModuleInterface..

[andreaTP]

what I'd like to do though (and I guess one often wants to) is to also implement the interop logic inside these export shims, like in our case consuming/transfering buffers and encoding/decoding protos.

That’s correct, the WasmModuleInterface handles the low-level plumbing. It’s typically wrapped by another layer or object where the higher-level logic is defined “on top” of those bindings.

For example, in this implementation , OpaPolicy serves as the user-facing API. Internally, it uses OpaWasm and all the generated code (via WasmModuleInterface) to provide the exposed functionality.

Personally, I tend to hand-roll the integration as much as feasible, but it’s absolutely possible to add more abstraction layers for example, through annotations and code generation, dynamic proxies, or similar patterns.

That said, this is the most “generic” pattern I’ve found, and it applies well across different Wasm modules. If you have ideas or feedback on how to evolve it, I’d be happy to discuss further 🙂