Queue representation / handling

Created by: marcus-oscarsson

Hi all,

Matias told me that he spoke with you about our ideas for queue handling and representation during the MxCuBE meeting. So we thought we would present our rough ideas.

We are thinking about a functional approach (like redux) for the queue, where a new queue representation is generated for each action performed on the queue. The queue representation is the very same one used by the queue store (JSON). This representation is then, surprise surprise :), exchanged between the client and the server. The server creates a new queue from the queue representation when a "SET SERVER QUEUE" request is sent . (Keep in mind that a queue can not be updated while its running.) The server in turn can send a "SET CLIENT QUEUE" request over a websocket, the only thing the client needs to do is to update the queue store.

The advantage with this approach is that the API to handle the queue becomes very simple you either do SET_SERVER_QUEUE or SET_CLIENT_QUEUE, and for the client in some cases GET_QUEUE. There will be no need for keeping track of node ids on the client, which can be error prone and difficult to maintain/debug. All in all it will be much easier to debug and the server side API is dramatically reduced.

The currently running task might have, if needed, and additional API to update for instance number of images or other progress. We however don't think this will be needed but we don't see it as a problem to handle this separately if needed.

I have already written the necessary code to perform the serialization and queue construction. The format I used are almost identical with the one that is used today.

Representation of queue:

{
    "1:01": [
        {
            "Type": "DataCollection", 
            "label": "Data Collection", 
            "parameters": {
                "detector_mode": "", 
                "energy": 0, 
                "exp_time": 0.0, 
                "first_image": 0, 
                "inverse_beam": false, 
                "kappa": 0.0, 
                "kappa_phi": 0.0, 
                "num_images": 0, 
                "num_passes": 0, 
                "osc_range": 0.0, 
                "osc_start": 0.0, 
                "overlap": 0.0, 
                "path": "/tmp/visitor/local-user/test/20160728/RAW_DATA/dummy_path", 
                "prefix": "", 
                "resolution": 0.0, 
                "run_number": 0, 
                "shutterless": false, 
                "snapshot": null, 
                "transmission": 0.0
            }, 
            "sampleID": "1:01", 
            "state": 0
        }
    ], 
    "1:02": [ ....

The construction of the queue from this representation is done on the server and all the client needs to do is to display it by updating the store.

We would like to make a PR applying these principles soon. We would really like your opinion and thoughts about these ideas since it has some impact on the SampleQueue components and the Queue route.

Cheers, Marcus