Allow concurrent clients

[albireox]

One major issue of the server right now is that it needs to run with only one worker since each worker will try to connect to the camera and the camera allows only one connection.

In general this is not super critical because most requests (get/set temperature, get status, etc.) are very fast and complete almost immediately. The two route that do block the server for a long time are moving the filter wheel and exposing. During an exposure it's not possible to check the temperature or abort the exposure.

I think there are three main options to deal with this:

1. Abstract the camera control a bit more (not too difficult) so that's not linked to the Flask app, and then store a single instance of the camera connection in a global state that can be accessed by all the workers. Probably that can be managed with some form of this or maybe by wrapping the camera in its own mini-server, separate from the Flask server.
2. Trying to avoid all long-blocking routes. Currently the main blocking route is capture. That route blocks (with a sleep) until the exposure is complete and then reads the buffer and saves the file. capture could be divided in two routes: start_capture which sets the parameters for the exposure, starts the integration and returns without blocking, and finish_capture that would be called once the exposure time has passed and would read the buffer and save the frame. This would require the client to be the one keeping track of the exposure time (or continuously poll until the status DRV_ACQUIRING goes away) then call finish_capture. Less critically, the same could be done for the filter wheel.
3. A variation of 2) in which we implement a system of push notifications or a websocket to allow communication between the client and the server without specific requests. That way the client could start the acquisition and the server would notify the client over the websocket when the exposure is complete, and all that could be done without blocking.

Option 2) is probably the easiest, but I think we would want to implement 3) in some form anyway. For example, the server could be continuously outputting the status and temperature to the websocket without the client having to poll for it, which would simplify the code. And it's actually easy to implement using al library like this one.

[ojf]

I have a feeling that option 3 will make future projects possible, since then the client can get unexpected messages. Will also probably make it simpler to code things like the autofocus Siyu's talking about (i.e. request a focus move, focus has finished moving, request an exposure, buffer is ready, read the buffer and measure it, repeat).