Module executor 

PluginExecutor — the dispatch seam across execution backends.

Fidius historically carried one dispatch implementation per backend: the cdylib vtable/FFI path lived inside PluginHandle, and the Python (PyO3) path lived in a separate PythonPluginHandle in fidius-python. This module collapses that duplication: each backend is an executor, and the caller-facing crate::handle::PluginHandle wraps them in an enum (Backend) so its generic call_method<I, O> can serialise with each backend’s native currency.

Why an enum, not Box<dyn> — and why two traits

The backends do not share a typed wire. cdylib decodes concrete-type bincode (not self-describing — it can’t be reconstructed from an erased value), while Python (and the future WASM component backend) consume a self-describing fidius_core::Value. A single call(method, Value) trait method therefore cannot serve cdylib without breaking its ABI (see FIDIUS-A-0003 / FIDIUS-I-0021 amendment). So:

• PluginExecutor is the common surface every backend shares: metadata plus the raw byte path. For cdylib, call_raw is also the carrier for typed calls (the wrapper bincode-wraps the concrete type).
• ValueExecutor adds the typed fidius_core::Value call, implemented only by the self-describing backends (Python, WASM). cdylib does not implement it — PluginHandle routes cdylib typed calls through its own bincode call_method, keeping the bytes byte-identical to pre-refactor.

Re-exports

pub use cdylib::CdylibExecutor;

Modules

cdylib

CdylibExecutor — the cdylib execution backend: vtable/FFI dispatch with the bincode wire format.

Traits

PluginExecutor

The surface every execution backend shares.

ValueExecutor

Backends whose typed boundary is the self-describing Value model — Python today, and the Phase-2 WASM component executor.