Namespace DotBoxD.Plugins.Runtime
Namespaces
Section titled “Namespaces”DotBoxD.Plugins.Runtime.Diagnostics
DotBoxD.Plugins.Runtime.Lifecycle
DotBoxD.Plugins.Runtime.Subscriptions
Classes
Section titled “Classes”HookPipeline<TEvent, TContext>
RemoteHookPipeline<TEvent, TContext>
Client-side hook registration surface for a remote plugin server. The fluent stages are lowered by
the analyzer; a Run terminal installs the generated verified-IR package through the supplied
control-plane callback, while a RunLocal terminal additionally registers its native delegate in
the supplied local-handler registry so the server can push filtered+projected values back to it.
RemoteSubscriptionPipeline<TEvent>
RemoteSubscriptionPipeline<TEvent, TContext>
Client-side fire-and-forget subscription registration surface for a remote plugin server. A
RunLocal terminal registers its native delegate in the supplied local-handler registry so the
server can push filtered+projected values back to it per matching event.
ResultHookDispatchOptions<TResult>
Per-dispatch options for result-returning hooks. Local handlers keep the existing in-process semantics; the timeout applies only to remote result handlers because they cross an IPC boundary that can stall.
A fault caught while dispatching a result-returning hook (.Register(…) / .RegisterLocal(…))
for one hook context type. HookRegistry.FireAsync isolates a faulting
handler — it abstains and falls through to the next registration so one bad handler cannot break the hook
point — but that isolation is otherwise silent, which would let a veto-bearing handler (a successful result
carrying e.g. CanDie = false) that throws fail open to the host default with no trace. The host
observes these faults via PluginServer.Create(onResultHookFault: …) to surface the failure in its
log, mirroring DotBoxD.Plugins.Runtime.SubscriptionDeliveryFault for fire-and-forget subscriptions. Control flow is
unchanged: a faulted handler is still skipped and dispatch still falls through to the next registration.
A fault caught while delivering a published event to a subscription. Delivery runs on a background task and
these faults are otherwise swallowed (so the game loop is never blocked or crashed by plugin code); the host
observes them via PluginServer.Create(onSubscriptionFault: …) to surface the failure in its log,
so a misbehaving Subscriptions.On<T>().Where(…).RunLocal(…) chain is diagnosable instead of
silently doing nothing.
SubscriptionPipeline<TEvent, TContext>
TypedInstalledKernel<TSettings>
Interfaces
Section titled “Interfaces”A type-erased, wire-capable view of a registered DotBoxD.Abstractions.IPluginEventAdapter. The closure is
captured once at registration time (when the event type is statically known), so the host-side router
(DotBoxD.Plugins.PluginServer.WireHook(DotBoxD.Plugins.Kernel.InstalledKernel,DotBoxD.Plugins.WireOptions) / DotBoxD.Plugins.PluginServer.WireSubscription(DotBoxD.Plugins.Kernel.InstalledKernel,DotBoxD.Plugins.WireOptions)) can wire an installed
kernel to the correct typed pipeline terminal by event name — with no reflection at wire time.
Public as a composability seam: resolve one via `DotBoxD.Plugins.Runtime.PluginEventAdapterRegistry.TryResolveErased(System.String,DotBoxD.Plugins.Runtime.IErasedPluginEventAdapter@)`
and wire a kernel your own way when the `DotBoxD.Plugins.PluginServer.WireHook(DotBoxD.Plugins.Kernel.InstalledKernel,DotBoxD.Plugins.WireOptions)` /
`DotBoxD.Plugins.PluginServer.WireSubscription(DotBoxD.Plugins.Kernel.InstalledKernel,DotBoxD.Plugins.WireOptions)` defaults don't fit — without dropping all the way back to a
hand-written event-name → typed-On<TEvent>() dispatch.
Which stage of subscription delivery threw. DotBoxD.Plugins.Runtime.SubscriptionDeliveryStage.Filter is a lowered server-side
Where/projection predicate; DotBoxD.Plugins.Runtime.SubscriptionDeliveryStage.Handler is a terminal handler (including a RunLocal
projection push and the native decode/dispatch it drives across the host boundary).