The generic FOSS proxy: ONE IAddon record standing in for ANY opaque kernel.
This is the Single-Source Lever of the marketplace story. A proprietary addon ships as a compiled binary and nothing else; the record that mounts it is this one, MIT-licensed, generic, and identical for every vendor. That the proxy is open is not a leak: it holds no kernel logic at all, only framing and delegation. All of the IP is in the binary.
The kernel SELF-DESCRIBES, so this record learns the addon's tools, hooks, exclusions and schema extensions from the running kernel rather than from the manifest. A manifest that enumerated them would be a second copy of the truth and would rot the first time the vendor shipped a new build.
What the manifest still supplies is what must be known BEFORE the kernel runs: the addon id and its advertised capabilities. The mount pipeline reads both while deciding whether this addon is licensed and where it sits in the dependency order, which is strictly before anything has been started.
The generic FOSS proxy: ONE IAddon record standing in for ANY opaque kernel. This is the Single-Source Lever of the marketplace story. A proprietary addon ships as a compiled binary and nothing else; the record that mounts it is this one, MIT-licensed, generic, and identical for every vendor. That the proxy is open is not a leak: it holds no kernel logic at all, only framing and delegation. All of the IP is in the binary. The kernel SELF-DESCRIBES, so this record learns the addon's tools, hooks, exclusions and schema extensions from the running kernel rather than from the manifest. A manifest that enumerated them would be a second copy of the truth and would rot the first time the vendor shipped a new build. What the manifest still supplies is what must be known BEFORE the kernel runs: the addon id and its advertised capabilities. The mount pipeline reads both while deciding whether this addon is licensed and where it sits in the dependency order, which is strictly before anything has been started.
(call! transport op args)Send one op to the kernel and answer its decoded RESPONSE MAP.
Never throws. A dead pipe, an unreadable answer and a kernel-side error all
come back as an :error response, because every caller here is an IAddon
method and the IAddon contract has no exception channel: health must
answer, tools must return a seq, a tool handler must return a result map.
Send one op to the kernel and answer its decoded RESPONSE MAP. Never throws. A dead pipe, an unreadable answer and a kernel-side error all come back as an :error response, because every caller here is an IAddon method and the IAddon contract has no exception channel: `health` must answer, `tools` must return a seq, a tool handler must return a result map.
(call-result! transport op args fallback)The :result of one op, or fallback when the call failed. For the IAddon
methods that must answer with a value of a fixed shape whatever went wrong.
The :result of one op, or `fallback` when the call failed. For the IAddon methods that must answer with a value of a fixed shape whatever went wrong.
(opaque-addon spec transport)Construct the proxy from an OpaqueSpec and an ITransport. The spec is data and the transport is behaviour, which is why one is injected and the other is described (Cardinality Decides the Construct).
Construct the proxy from an OpaqueSpec and an ITransport. The spec is data and the transport is behaviour, which is why one is injected and the other is described (Cardinality Decides the Construct).
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |