JFly02
9457666fd6
Die Host-Seite ist jetzt auf eine gemeinsame software-first API ausgerichtet. In [control.rs](</c:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/control.rs>) steckt jetzt das stabile gemeinsame Modell für Snapshots, Commands, Pattern-Katalog, Presets, Gruppen, Parameter, Preview und Übergänge. Darauf sitzen die neue Szenen-/Pattern-Schicht in [scene.rs](</c:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/scene.rs>) und der simulationsbasierte Host-Service in [simulation.rs](</c:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/simulation.rs>). Der neue Core kann jetzt softwareseitig schon: - Pattern-Katalog mit `solid_color`, `gradient`, `chase`, `pulse`, `noise`, `walking_pixel` - Preset-Recall, Gruppen-Targeting, Parameteränderungen und Übergänge - simulierte Preview-Daten für alle 18 Outputs - denselben API-Zugriff für CLI, Engineering-GUI und später Web-UI / grandMA-Adapter Zusätzlich gibt es im Host-CLI jetzt `snapshot`, also eine direkte JSON-Sicht auf den gemeinsamen Host-State über [main.rs](</c:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/main.rs>). **Oberflächen** Die technische lokale GUI bleibt bestehen und hängt jetzt auf der neuen gemeinsamen API. In [app.rs](</c:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host_ui/src/app.rs>) zeigt sie weiter Mapping/Status/Testmuster, ergänzt um Engine-/Szene-/Übergangsstatus. Sie bleibt bewusst Engineering-orientiert und ist nicht zur kreativen Hauptoberfläche aufgeblasen worden. Die Beispielkonfiguration in [project.example.toml](</c:/Users/janni/Documents/RFP/Infinity_Vis _Rust/config/project.example.toml>) ist jetzt auch als Software-Spielwiese brauchbarer: mehr Gruppen, mehr kreative Presets und bessere Basis für Look-Entwicklung ohne echte Node-Aktivierung. Die neue API-Ausrichtung ist in [host_api.md](</c:/Users/janni/Documents/RFP/Infinity_Vis _Rust/docs/host_api.md>) und [architecture.md](</c:/Users/janni/Documents/RFP/Infinity_Vis _Rust/docs/architecture.md>) dokumentiert. **Verifikation** `cargo check` und `cargo test -q` laufen erfolgreich. Zusätzlich läuft `cargo run -p infinity_host -- snapshot --config config/project.example.toml` und liefert den gemeinsamen Host-Snapshot mit Katalog, aktiver Szene, Preview, Node- und Panelstatus. Der nächste sinnvolle Schritt ist jetzt ein echter API-Adapter fuer die kommende Web-UI, also HTTP/WebSocket auf genau diesem Host-Core statt einer frontend-spezifischen Parallelarchitektur.
81 lines
2.0 KiB
Markdown
81 lines
2.0 KiB
Markdown
# Host API
|
|
|
|
## Purpose
|
|
|
|
The host API is the stable boundary that all operator surfaces and later external show-control adapters must use.
|
|
|
|
Current rule:
|
|
|
|
- no UI is allowed to become the realtime clock
|
|
- no frontend-specific assumptions are allowed to leak into scene simulation or transport planning
|
|
- future grandMA support must land as an adapter on this API, not as a special-case core path
|
|
|
|
## Current Implementation
|
|
|
|
The API lives in:
|
|
|
|
- `crates/infinity_host/src/control.rs`
|
|
- `crates/infinity_host/src/scene.rs`
|
|
- `crates/infinity_host/src/simulation.rs`
|
|
|
|
The engineering GUI already consumes this API through the `HostApiPort` / `HostUiPort` trait boundary.
|
|
|
|
## Snapshot Model
|
|
|
|
`HostSnapshot` currently exposes:
|
|
|
|
- system metadata
|
|
- global controls
|
|
- engine timing and transition state
|
|
- catalog of patterns, presets, and groups
|
|
- active scene with parameter values
|
|
- simulated preview panels
|
|
- node and panel status
|
|
- recent event log
|
|
|
|
This makes it suitable as the shared read model for:
|
|
|
|
- engineering GUI
|
|
- upcoming web UI
|
|
- CLI inspection
|
|
- later external control bridges
|
|
|
|
## Command Model
|
|
|
|
`HostCommand` currently supports:
|
|
|
|
- blackout
|
|
- master brightness
|
|
- pattern selection
|
|
- preset recall
|
|
- group selection
|
|
- scene parameter changes
|
|
- transition duration changes
|
|
- per-panel test triggers
|
|
|
|
## Simulation Layer
|
|
|
|
The current `SimulationHostService` is not a throwaway mock. It is the software-first runtime for:
|
|
|
|
- look exploration
|
|
- preset development
|
|
- parameter tuning
|
|
- future web UI integration
|
|
- API contract testing before hardware activation
|
|
|
|
It simulates:
|
|
|
|
- active scene state
|
|
- pattern rendering previews
|
|
- group gating
|
|
- transitions
|
|
- node connectivity status
|
|
- per-panel mapping tests
|
|
|
|
## Near-Term Direction
|
|
|
|
1. Keep extending this API instead of adding surface-specific data paths.
|
|
2. Add a network-facing adapter for the same API when the web UI starts.
|
|
3. Keep engineering GUI focused on topology, mapping, diagnostics, and admin.
|
|
4. Add grandMA later as an external show-control adapter against this API.
|