📄️ Plug-in System
Plug-ins can be a fuzzy concept to grasp. The most accurate description is also the most abstract: A Plug-in is a software component that can extend the functionality of your application. But how is this different from any other piece of code?
A plug-in is a code module that conforms to the interface of your Plug-in System. In Extism, a plug-in is ultimately a WebAssembly Module that can be created using one of our PDKs in the language of your choice.
📄️ Host SDKs
In Extism parlance, we call the application that your plug-ins extend the host. e.g: in VS Code, if the extensions are the plug-ins then the editor itself is the host.
📄️ Host Functions
If you find yourself wanting to provide a plug-in with more custom capabilities, beyond what Extism
📄️ Plug-in Development Kits (PDKs)
Using an official Plug-in Development Kit (PDK) makes it simple to write code which can be compiled to WebAssembly and run within an Extism Host environment.
Passing variables and data into and out of WebAssembly (Wasm) isn't trivial as the host and the WebAssembly have separately managed memory and often use differing ABIs for variables and function calls. The Extism framework provides a general purpose solution to ease passing data between the host and Wasm. Extism implements this by managing memory isolated from both the host and the plug-in/Wasm module.
📄️ The Manifest
The manifest is a description of your plugin and some of the runtime constraints to apply to it. You can think of it as a blueprint to build your plugin.
Generally speaking, all configuration is defined at the Host level. As a plug-in, you are able to configuration data that has been provided by a Host, but you cannot edit runtime configuration. The sections below go into further detail about configurability, as well as some advanced functionality which require Extism to be built from source with specific feature flags.
📄️ Runtime APIs
The Extism runtime is implemented as a Rust crate and has a C API. The C API enables embedding the runtime in any language with C-compatible FFI. Many of the official SDKs are built on top of the C API.