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.

Sign up for GitHub

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

Jump to bottom

Add Observe SDK support #3

Open
bhelx opened this issue Sep 19, 2023 · 2 comments
Open

Add Observe SDK support #3

bhelx opened this issue Sep 19, 2023 · 2 comments

Comments

@bhelx
Copy link
Contributor

bhelx commented Sep 19, 2023 •
edited
Loading

This is different than extism/extism#470

Because we don't rely on libextism in this library, I believe we should be able to add Observe support independently.
@bhelx bhelx mentioned this issue Sep 25, 2023
Closed
@neuronicnobody neuronicnobody added the enhancement New feature or request label Oct 2, 2023
@neuronicnobody
Copy link

Wait for Observe SDK breaking changes to land . Ping @chrisdickinson

@chrisdickinson
Copy link
Contributor

chrisdickinson commented Nov 16, 2023 •
edited
Loading

In order to accomplish this, we need to:

@neuronicnobody neuronicnobody added question Further information is requested and removed enhancement New feature or request question Further information is requested labels Nov 27, 2023
chrisdickinson added a commit that referenced this issue Nov 27, 2023
@chrisdickinson
feat: accept WebAssembly.Module, Response inputs
07b6aa7 
`createPlugin` now accepts two additional manifest types (`response` and `module`) as well
as `Response` and `WebAssembly.Module`. There are four goals here:

1. Allow us to target the Cloudflare Workers platform. CF Workers only support
   loading Wasm via `import` statements; these resolve to `WebAssembly.Module`
   objects, which means we need to allow users to pass `Module`s in addition
   to our other types.
2. Play nicely with V8's [Wasm caching][1]; in particular V8 will use metadata
   from the `Response` to build a key for caching the results of Wasm compilation.
3. This sets us up to implement [Wasm linking][2] by allowing us to introspect
   plugin modules imports and exports before instantiation.
4. And finally, resolving to modules instead of arraybuffers allows us to add
   [hooks for observe-sdk][3] (especially in advance of adding [thread pooling][4]).

Because Bun lacks support for `WebAssembly.compileStreaming` and
`Response.clone()`, we provide an alternate implementation for converting a
response to a module and its metadata.

One caveat is that there's no way to get the source bytes of a
`WebAssembly.Module`, so `{module}` cannot be used with `{hash}` in a
`Manifest`.

Fixes #9

[1]: https://v8.dev/blog/wasm-code-caching#stream
[2]: #29
[3]: #3
[4]: #31
@chrisdickinson chrisdickinson mentioned this issue Nov 27, 2023
Merged
chrisdickinson added a commit that referenced this issue Nov 27, 2023
@chrisdickinson
feat: accept WebAssembly.Module, Response inputs
43153f7 
`createPlugin` now accepts two additional manifest types (`response` and `module`) as well
as `Response` and `WebAssembly.Module`. There are four goals here:

1. Allow us to target the Cloudflare Workers platform. CF Workers only support
   loading Wasm via `import` statements; these resolve to `WebAssembly.Module`
   objects, which means we need to allow users to pass `Module`s in addition
   to our other types.
2. Play nicely with V8's [Wasm caching][1]; in particular V8 will use metadata
   from the `Response` to build a key for caching the results of Wasm compilation.
3. This sets us up to implement [Wasm linking][2] by allowing us to introspect
   plugin modules imports and exports before instantiation.
4. And finally, resolving to modules instead of arraybuffers allows us to add
   [hooks for observe-sdk][3] (especially in advance of adding [thread pooling][4]).

Because Bun lacks support for `WebAssembly.compileStreaming` and
`Response.clone()`, we provide an alternate implementation for converting a
response to a module and its metadata.

One caveat is that there's no way to get the source bytes of a
`WebAssembly.Module`, so `{module}` cannot be used with `{hash}` in a
`Manifest`.

Fixes #9

[1]: https://v8.dev/blog/wasm-code-caching#stream
[2]: #29
[3]: #3
[4]: #31
chrisdickinson added a commit that referenced this issue Nov 28, 2023
@chrisdickinson
feat: accept WebAssembly.Module, Response inputs (#32)
630fcd6 
`createPlugin` now accepts two additional manifest types (`response` and `module`) as well
as `Response` and `WebAssembly.Module`. There are four goals here:

1. Allow us to target the Cloudflare Workers platform. CF Workers only support
   loading Wasm via `import` statements; these resolve to `WebAssembly.Module`
   objects, which means we need to allow users to pass `Module`s in addition
   to our other types.
2. Play nicely with V8's [Wasm caching][1]; in particular V8 will use metadata
   from the `Response` to build a key for caching the results of Wasm compilation.
3. This sets us up to implement [Wasm linking][2] by allowing us to introspect
   plugin modules imports and exports before instantiation.
4. And finally, resolving to modules instead of arraybuffers allows us to add
   [hooks for observe-sdk][3] (especially in advance of adding [thread pooling][4]).

Because Bun lacks support for `WebAssembly.compileStreaming` and
`Response.clone()`, we provide an alternate implementation for converting a
response to a module and its metadata.

One caveat is that there's no way to get the source bytes of a
`WebAssembly.Module`, so `{module}` cannot be used with `{hash}` in a
`Manifest`.

Fixes #9

[1]: https://v8.dev/blog/wasm-code-caching#stream
[2]: #29
[3]: #3
[4]: #31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@chrisdickinson @bhelx @neuronicnobody