-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebUI: Use websockets instead of http polling/API #52
Comments
Some references (all seem to implement a custom http server on top of lwIP): |
It would be nice to keep a basic JSON API too if possible if it doesn't add too much codespace, as that's much easier for people just hacking around with the board wanting random integration. Although I appreciate it's probably not the best way to e.g. send DMX data to it. |
Yes, the JSON API is meant to stay, even if websockets are implemented for exactly the reasons you mentioned :) |
Currently the Web UI uses HTTP call to the device's API to get/update information like device status, buffer content (Console page), log entries, wireless status counters. Usually, a one second update polling interval is being used which makes the Console seem laggy when the values update often or fade. Websockets provide a nice way to make the Web UI more responsive and faster. Some "live audio mixers" that can be controlled via web browser from a tablet or similar uss websockets for control and signal level display (Soundcraft's Ui series).
The client/browser part should not be a problem (and a fallback to polling could be done if the user-agent doesn't support websockets). On the server side (lwIP stack and its http server) impementation will be quite some effort.
The text was updated successfully, but these errors were encountered: