Expand description
§csi-webclient
Native Rust desktop client for controlling csi-webserver through REST and WebSocket APIs.
This crate ships the full application and exposes modules that keep UI code, state, and side effects separate so behavior stays maintainable as protocol features evolve.
§Module Layout
app: top-level orchestration that translatesUserIntentvalues into core commands and applies core events back into app state.state: source-of-truth state models, user intents, and API-facing enum mappings.core: side-effect layer for HTTP requests, WebSocket receive loop, and worker runtime.ui: rendering modules for each tab (dashboard/config/control/stream) without direct IO.
§Runtime Flow
- UI interactions enqueue intents in
state::AppState. app::CsiClientAppdrains intents and submitscore::messages::CoreCommandvalues.coreexecutes HTTP/WebSocket side effects on a worker thread and Tokio runtime.coreemitscore::messages::CoreEventvalues over channels.app::CsiClientApppolls and applies events to state on each frame.
This design avoids blocking work in the egui frame callback and keeps network concerns out of view code.
§API Coverage
The client targets these server routes:
GET /api/configPOST /api/config/resetPOST /api/config/wifiPOST /api/config/trafficPOST /api/config/csiPOST /api/config/collection-modePOST /api/config/log-modePOST /api/config/output-modePOST /api/control/startPOST /api/control/resetGET /api/ws
For detailed request/response behavior and payload fields, see:
§Protocol Values Used By The Client
- Wi-Fi modes:
sta,monitor,sniffer - Collection modes:
collector,listener - Log modes:
text,array-list,serialized - Output modes:
stream,dump,both
§Notes
- HTTP success is treated as status code in the
2xxrange. - API responses are parsed best-effort from either a generic envelope
(
success/message/data) or direct JSON payload. - WebSocket text and binary messages are both stored as frame bytes for stream inspection.