To consume wit files, we would need a bindgen procedural macro which will consume the interface, and generate all necessary inferface types and functions, as well as the relevant traits to implement for the host exports.
To do this, we could leverage the existing wasmtime wit_bindgen macro and slightly modify it to fit this crate and its exports.
For supporting custom structs and enums we would need a ComponentLift ComponentLower trait that will declare how to convert this rust side struct into a the ValueType::Record type, or directly into the guest memory.
The conversion into Value would allow utilizing existing marshalling code, but comes at the cost of the conversion and boxing of the values due to the recursive nature of the enum. If used in a hotloop, this would likely become expensive, though far from as expensive at generating recursive JsObjects with stringed key-value pairs which JCO employs.
Using a direct memory write would be more code, but it would allow an flow-inversion where the existing Value would instead implement that Lift and Lower traits. As such, this method will still ensure a consistent and predictable model without shortcuts or circumventions of existing logic.
Let me know what you think and if you have any particular requests or considerations 😊
To consume
witfiles, we would need a bindgen procedural macro which will consume the interface, and generate all necessary inferface types and functions, as well as the relevant traits to implement for the host exports.To do this, we could leverage the existing wasmtime
wit_bindgenmacro and slightly modify it to fit this crate and its exports.For supporting custom structs and enums we would need a
ComponentLiftComponentLowertrait that will declare how to convert this rust side struct into a theValueType::Recordtype, or directly into the guest memory.The conversion into
Valuewould allow utilizing existing marshalling code, but comes at the cost of the conversion and boxing of the values due to the recursive nature of the enum. If used in a hotloop, this would likely become expensive, though far from as expensive at generating recursiveJsObjects with stringed key-value pairs which JCO employs.Using a direct memory write would be more code, but it would allow an flow-inversion where the existing
Valuewould instead implement that Lift and Lower traits. As such, this method will still ensure a consistent and predictable model without shortcuts or circumventions of existing logic.Let me know what you think and if you have any particular requests or considerations 😊