I'm assuming if I have a component model component wasm file that I can't run that in a runtime that doesn't support the component model (I'm thinking of running plugins on the JVM with chicory for example).
If this is the case, are their build steps I can do on a component model built component to make it capable of running on a runtime with no component model support?
Also I realize another issue I might face is my plugins using WASI 0.2.0 and a platform like chicory seems to only su[pport preview 1, is there anything I can do in a build step to mitigate/polyfill this?
To be clear, I am looking to build out a host and extension mechanism.
For some of the platforms I am targeting to be able to run my host component component model and preview 2 is available (Rust, Go, TypeScript, and Python... I think .NET too), but I also need to support the JVM and it seems embedding a runtime in the JVM is limited and none of the solutions I see support component model and WASI preview 2.
I'm fairly new to trying to build something so I can be off (though I've been tracking progress of things in the space for a few months).
I don't believe there are any existing solutions for this. JCO does this for JS WebAssembly with a combination of preprocessing and host runtime support: https://github.com/bytecodealliance/jco
there's also @Christof Petig's preview2 adapter, which I think is a meaningful step towards this
JCO does convert the component to a WASM module module that can run on the web (and indeed any WASM runtime without component model support) and it even generates JS bindings for you. But if your runtime is not in javascript, then you will have to manipulate the bytes directly yourself, which is difficult, but possible. I am doing the same thing in Rust, where I take the JCO-transpiled WASM module and manipulate the bytes directly myself.
Last updated: Dec 23 2024 at 12:05 UTC