Decoupling "client" and "server"

[jghibiki]

Have you considered decoupling the system into a series of "clients" and a "server". e.g. One websocket server that is free to run asynchronously which is then communicating with clients asynchronously via websockets? This would allow for client/frontend development to be relatively free of the operational constraints of the server.

It would also allow clients to be implemented using other languages, and if networked plugins were allowed, it would allow for better interoperability with other IOT services e.g. frontend is a WS client, plugin is a WS client, server handles some commands internally but WS clients can register new commands with the server, that when the command is issued by the frontend client it is relayed to the server which then broadcasts that command to the WS plugin which manages its own state and handles the operation and then can make core api calls to the server. if a response to the frontend is required, it is sent to the server which routes the response to the client.

This would also make the stability of the system independent of the stability of a plugin. If the plugin doesn't respond the server can tell the frontend there was an error and continue on without additional error handling.

Frontend clients e.g. the terminal client, a voice client, etc. could then be self contained and the implementation for each would not be wholly dependent on the server.

Just food for thought. If you were interested in going this route, i would be wiling to look into websocket server implementations. I already have experience in python with Autobahn and Asyncio which make the process such a breeze. However i am not personally sure the state of C++ async abilities or websocket libraries.

May help provide a way to make #29 , #30 , and #31 server independent.