-
Notifications
You must be signed in to change notification settings - Fork 0
Home
GDX supports third-party modules (plugins): full-stack extensions an operator installs into their own instance, each with its own backend and its own (server-rendered) UI.
Status: in development. The architecture is settled (see ADR-013) and is being built in 6 steps. This wiki grows with the build — each page notes what is implemented vs. pending so you can tell the difference.
- Using Plugins — for operators: installing, enabling, updating.
- Authoring Plugins — for developers: building a plugin package.
Plugins are ordinary pip packages that register under the gdx.modules
entry-point group. They run inside a dedicated plugin-host container
(isolated from the core app — the VS Code "Extension Host" model), which the core
app proxies to. Plugins ship no browser JavaScript: their UI is declared as
data and rendered by the host. Operators vet what they install; there is no
central registry or signing.
| Step | What | Status |
|---|---|---|
| 1 |
gdx.plugin_api foundation — manifest, discovery, version gate |
✅ implemented |
| 2 |
PluginBase + auth/DB context, require_module re-export |
⏳ pending |
| 3 |
plugin-host container + /api/plugins/* proxy |
⏳ pending |
| 4 | UI-manifest schema + host renderer | ⏳ pending |
| 5 |
plugin_registry + in-app install/reconcile |
⏳ pending |
| 6 | Reference plugin (gdx-plugin-example) |
⏳ pending |