Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plans to support component model? #2200

Closed
purplefox opened this issue May 1, 2024 · 5 comments
Closed

Plans to support component model? #2200

purplefox opened this issue May 1, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@purplefox
Copy link

Hi All,

Sorry for using an issue to ask a question, but didn't know how else to do this.

I started using wazero recently as a way to run custom functions in the database we are building. My experience so far is very positive!

Do you have plans to support component model, so we can have a standard, non custom way to pass complex types (strings, byte arrays etc) to and from wasm modules? Any timeline for this?

@purplefox purplefox added the enhancement New feature or request label May 1, 2024
@evacchi
Copy link
Contributor

evacchi commented May 1, 2024

We currently do not have sharable roadmaps in this regard.

@mathetake
Copy link
Member

sorry the answer is definitely no until it is standardized in the w3c recommendation, which I don't think will happen in at least for the next 5 years or so.

@mathetake mathetake closed this as not planned Won't fix, can't repro, duplicate, stale May 2, 2024
@purplefox
Copy link
Author

purplefox commented May 2, 2024

Thanks for your replies.

In the absence of component model support in the foreseeable future, do you have any other approach in mind for making it easier to support complex parameter types? For Rust/Go its not so bad as we can malloc/free in the module do unsafe casts to memory but this isn't possible in all languages that have WASM support, thus making them pretty much unusable for use cases such as user defined functions running in a database (unless all params are int/float which is extremely restrictive)

@evacchi
Copy link
Contributor

evacchi commented May 2, 2024

usually people provide a form of SDK and hide the serialization routines from the end users. Some approaches I have seen in the wild are based e.g. on protobuf (although generated code tends to be large) for instance see https://github.com/knqyf263/go-plugin or other serialization formats. If performance is not an issue I personally have used JSON because all languages have built-in support for it (especially on POCs)

Also, you might want to checkout Extism, their Go runtime is based on wazero. Their solution is probably a bit more opinionated than just a library, but it might be a good fit depending on your workload; personally I like it https://extism.org/docs/concepts/host-sdk

@nilslice
Copy link
Contributor

@purplefox - if I may add another suggestion here, we recently added support to Extism (a universal wasm plugin system) for rich types using an open schema (similar to OpenAPI) called XTP Schema. You can read about it here: https://extism.org/blog/announcing-xtp-bindgen as well as its official docs at https://docs.xtp.dylibso.com/docs/concepts/xtp-schema

Using the xtp CLI, It works much the same way as the WIT tooling for Component Model, except it will produce code to write Wasm modules which run in practically every wasm runtime. Feel free to join us on Discord or Slack to get more information if you are interested: https://docs.xtp.dylibso.com/docs/support/

For more information about it, how we support XTP, and the motivation behind it, you can also check out this recent post about our platform, however all XTP schema and code generators are free and open source: https://www.getxtp.com/blog/meet-xtp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants