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

Stubless RPC PoC get stub type information #1149

Closed
vigoo opened this issue Dec 6, 2024 · 1 comment · May be fixed by #1199
Closed

Stubless RPC PoC get stub type information #1149

vigoo opened this issue Dec 6, 2024 · 1 comment · May be fixed by #1199
Assignees
Milestone

Comments

@vigoo
Copy link
Contributor

vigoo commented Dec 6, 2024

The second research step before implementing the real stubless RPC linker. Based on #1148 we know exactly what amount of type information we need to do that hardcoded mapping from wasmtime's internal representation into our RPC representation.

The outcome of this ticket is to have a way to get this information in the worker executor for an arbitrary component.

Some approaches to choose from:

  • analyse the component model data just like we do for finding exported functions
  • use the embedded binary wit custom section
  • upload extra metadata (wits, or preprocessed information) from client side
@vigoo vigoo self-assigned this Dec 6, 2024
@vigoo vigoo added this to the Golem 1.2 milestone Dec 6, 2024
@vigoo
Copy link
Contributor Author

vigoo commented Dec 15, 2024

It is possible that we don't need actual type information - as the component is already parsed and we have what wasmtime exposes. In this case maybe adding a generic "dynamic linked interface" lists to component metadata would work, where you would have to list the dynamic stubs in your app manfest and this would get into the component metadata with optional "linker-specific payload" which we don necessarily need to use here, but can be useful for dynamic grpc/openapi stubs etc.

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

Successfully merging a pull request may close this issue.

1 participant