Closed cpieloth closed 4 years ago
It seems like you are reading my mind.. I was planing to open an issue about the same thing today.
Also, I have been working on the MNE-Python real-time client. This client makes very minimal assumptions about the commands supported (only start, stop, measinfo), all other commands are parsed automatically from the JSON help string. This means that the help string has to be correct, otherwise the commands sent be the client will be wrong. Right now, the JSON help string is hard-coded, separate from the actual implementation of the commands. This isn't ideal, as it means more work when adding commands and also poses the risk of having the help text being out-of-sync with the actually supported commands.
I propose that we extend the Command
class to include name, type, and description of all parameters and return values. This will allow us to generate the JSON help at runtime. In addition, this can probably be used for parameter parsing as well.
@chdinh any comments?
sorry guys - I will care about it asap.
Closing this issue. The Neuromag plugin in mne_rt_Server has been replaced by the fieldtrip buffer plugin in MNE Scan.
This is a feature request for a Return Code for a Command response.
Problem: After sending a Command from a rt client to a mne_rt_server, there is no possibility to check whether it was successful or not.
Idea: Extend the JSON response by a return code e.g. status with values 0 for success, 1 for a general error, >1 for command specific errors. Additionally something like a optional status text/description could be very helpful for debugging and user output. A third argument contains the actual response.
Example: Request -> conlist JSON Response - >success
JSON Response -> error
A command client can check/return the success of a command and an application can handle errors.