The websocket API that I wrote is currently designed to minimize the clientside processing effort. The current test UI just sends single commands to the backend, and posts messages that it receives from the backend (it does not know which backend response corresponds with which request, and does not do any additional processing with it anyway). This works for testing, but might not be what we want for production.
Joel (or anyone else working on the frontend) let me know what changes I should make to the websocket protocol to support your WebUI.
Well, if I look at the interactions we had on volumio 1.5, most commands can be used with simple websocket events (play, pause, previous next etc.). It’s ok for 80% of the webui. There’s no response expected.
The other 20% are for browsing files (mpd lsinfo), searching, and I will probably want to have access to the whole library. For those requests we’ll need to have “conversations” through websockets. A possibility is that the client sets a token in the websocket message (like: { _token: “abcd”, otherstuff: {} } ) and when the server see a token it includes it in the response.