You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we use JsValueTransport to facilitate moving values between the rb-abi-host and rb-abi-guest. Since the introduction of this workaround in #18 (May 2022), the WIT format implemented features such as worlds and import/exports. If we update our .wit files to use these new features I think JsValueTransport would no longer needed because the host and guest .wit can reference each other.
The text was updated successfully, but these errors were encountered:
Created a single wit directory where we store both .wit files as suggested by the WIT docs
Wrap each file's current content inside an interface
Use a use statement to reference js-abi-value in guest and rb-abi-value host
This may need a good bit of reorganizing of the current project structure. I'm frankly unsure what implications moving files around will have (especially in regards to C files currently in the same directory as the .wit files). I would appreciate some insight on this.
Thank you for your proposal! Yeah, I'm positive for using the latest WIT spec's import/export to describe the hack in the right way. It looks like wit-bindgen now supports resource feature in C. Also we can use jco to import the component from JS host side.
Currently, we use
JsValueTransport
to facilitate moving values between the rb-abi-host and rb-abi-guest. Since the introduction of this workaround in #18 (May 2022), the WIT format implemented features such as worlds and import/exports. If we update our .wit files to use these new features I thinkJsValueTransport
would no longer needed because the host and guest .wit can reference each other.The text was updated successfully, but these errors were encountered: