- Adds `allowed_hosts` to the manifest
- If there are any `allowed_hosts` then `extism_http_request` checks to
make sure a URL's host is listed before performing the reques
- Adds `ExtismContext` instead of global `PLUGINS` registry
- Adds `extism_context_new`, `extism_context_free` and
`extism_context_reset`
- Requires updating nearly every SDK function to add context parameter
- Renames some SDK functions to follow better naming conventions
- `extism_plugin_register` -> `extism_plugin_new`
- `extism_output_get` -> `extism_plugin_output_data`
- `extism_output_length` -> `extism_plugin_output_length`
- `extism_call` -> `extism_plugin_call`
- Updates `extism_error` to return the context error when -1 issued for
the plug-in ID
- Adds `extism_plugin_free` to remove an existing plugin
- Updates SDKs to include these functions
- Updates SDK examples and comments
Co-authored-by: Steve Manuel <steve@dylib.so>
Adds a script to check which runtime API functions are not used in each host SDK. Provides a coverage report with percent of functions called in each SDK.
Co-authored-by: Steve Manuel <steve@dylib.so>
This PR fixes an issue where large allocations are currently causing
some arithmetic to wrap which caused a panic.
This was discovered by calling `http_get` on `youtube.com` from the http
example in the Rust PDK
This PR updates `extism_output_get` to return an actual pointer to the
output value (`const uint8_t* extism_output_get(PluginIndex plugin)`
instead of `void extism_output_get(PluginIndex plugin, uint8_t *buffer,
uint64_t length)`), this pointer will only be valid until the next call,
but it makes it possible to access the output data without copying.
The input buffer is also not copied and the same issue applies:
the input buffer must not change during `call`.
Co-authored-by: Steve Manuel <steve@dylib.so>
This gives host the ability to re-use plugin descriptors instead of
loading a new plugin each time. The plugin memory and everything is
reset, so no state is shared with the newly loaded plugin.
Co-authored-by: Steve Manuel <steve@dylib.so>
I noticed when calling set_log_file that it's on the top-level namespace.
And so is the rest of the gem. It's not a good idea to do this as it
pollutes the user's application. Best practice is to wrap all code in a
module which by convention is the gem name.
I was also getting `Uninitialized constant FFI:NIL` and in the
set_log_file method and I could not tell why it was needed. I changed it
to a regular ruby nil. If it's needed for some reason I'll change it
back or move to another PR.
