#[repr(C)]pub struct CustomE2eOpCallback {
pub cb: CustomE2eOpCallbackType,
pub ctx: OptionRefAny,
pub op_schema: Json,
}Expand description
Application-provided handler for E2E ops the engine does not implement.
Fields§
§cb: CustomE2eOpCallbackType§ctx: OptionRefAny§op_schema: JsonDescribes every op cb answers: name, summary, description, the JSON
type each argument expects, usage examples, and example returns.
DATA, not a second callback — discovery is a field read, so it needs
no invocation and no debug HTTP server. That is what lets a plugin
enumerate host capabilities, a locally-spawned MCP server expose the
app to an agent that would otherwise drive it by screenshot, or a
script.json be handed straight to the binary.
The examples and types are not documentation garnish: they are what a macro picker renders and what an agent reads in place of a screenshot.
Json deliberately, not typed structs — the schema can then follow an
OpenAPI-style operation shape and gain fields without an ABI break.
Typed structs come later.
Trait Implementations§
Source§impl Clone for CustomE2eOpCallback
impl Clone for CustomE2eOpCallback
Source§impl Debug for CustomE2eOpCallback
impl Debug for CustomE2eOpCallback
Source§impl Default for CustomE2eOpCallback
impl Default for CustomE2eOpCallback
Source§impl Display for CustomE2eOpCallback
impl Display for CustomE2eOpCallback
impl Eq for CustomE2eOpCallback
Source§impl From<extern "C" fn(RefAny, AzString, AzString) -> CustomE2eOpResult> for CustomE2eOpCallback
impl From<extern "C" fn(RefAny, AzString, AzString) -> CustomE2eOpResult> for CustomE2eOpCallback
Source§fn from(cb: CustomE2eOpCallbackType) -> Self
fn from(cb: CustomE2eOpCallbackType) -> Self
Installs a handler that advertises NOTHING.
A bare fn pointer carries no schema, so this cannot invent one. An app
converting from a fn pointer gets a working handler whose ops are
undiscoverable until it sets op_schema — visible in a plugin listing
as an empty op list, which is the honest answer rather than a guess.