The webserver is currently treated completely differently from any other device. It takes the device manager as an attribute, making it the webserver "master" in some peculiar ways. The device manager should act as the central router for all messages, completely agnostic to the nature of the devices. This makes the code easier to follow and future-proofs it in case someone decides to replace the web-based user interface with SkyNet.
Best solution is for the webserver to be its own device. It can send and receive messages via the device manager, just like hardware devices. We can then spec the program such that a device with the name "controller" is required, and then have the default destination be "controller" for messages.
wrap the webserver in a RobotDevice instance
give Tornado its own multiprocessing queue (not direct access to the private DeviceManager queues!) and have it pass messages to the device manager like any other device.
harmsm
commented
7 years ago
The webserver is currently treated completely differently from any other device. It takes the device manager as an attribute, making it the webserver "master" in some peculiar ways. The device manager should act as the central router for all messages, completely agnostic to the nature of the devices. This makes the code easier to follow and future-proofs it in case someone decides to replace the web-based user interface with SkyNet.
Best solution is for the webserver to be its own device. It can send and receive messages via the device manager, just like hardware devices. We can then spec the program such that a device with the name "controller" is required, and then have the default destination be "controller" for messages.