Api and Handler overhaul

.gitignore

@@ -14,4 +14,5 @@ server/src/.vscode/
 **/.vscode
 **/.cache
 **.project
-**jsconfig.json
+**jsconfig.json
+**/.env

README.md

@@ -21,7 +21,7 @@ libgcrypt, libpthread, libglib-2.0, libyaml,
 * KIELER command line compiler: [kico.jar](https://rtsys.informatik.uni-kiel.de/~kieler/files/nightly/sccharts/cli/)
   * Path to the folder that contains `kico.jar` has to be defined in the environment variable `KIELER_PATH`
 * BahnDSL command line compiler: [bahnc](https://github.com/trinnguyen/bahndsl)
-  * Path to the folder that contains the `bahnc` has to be defined in the environment variable `BAHNDSL_PATH`
+  * Path to the folder that contains the `bahnc` has to be defined in the environment variable `BAHNC_PATH`
 * SCCharts verifier: [SWTbahn Verifier (SWT internal repository)](https://gitlab.rz.uni-bamberg.de/swt/swtbahn-verifier)
 
 #### Command Line Client
@@ -70,9 +70,9 @@ client from a different working directory for the current session, otherwise it
 won't find the configuration file. If you really want to use two logically
 different clients on the same device, you could just run the clients from
 different working directories which will lead to distinct configs.
-3. Now you can use the commands from the categories `swtbahn admin`,
-`swtbahn controller`, `swtbahn driver` and `swtbahn monitor`. If the system was
-not started by `swtbahn admin startup`, all the other commands won't work.  
+3. Now you can use the commands from the roles `admin`,
+`controller`, `driver` and `monitor`. If the system was
+not started by `admin startup`, all the other commands won't work.  
 
     For example:  
     `./swtbahn admin startup`  
@@ -230,12 +230,16 @@ As an example, when a request is made to set point10 to the normal state, the re
 > _Intervening log messages from internal processing_   
 > LOG_NOTICE: `Request: Set point - point: point10 state: normal - finish`   
 
-If the above request was instead made with an unsupported state, e.g., `foobar`, then the request handler would generate the following log messages to say that the processing was stopped because of invalid parameters: 
+If the above request was instead made with an unsupported state, e.g., `foobar`, then the request handler would generate the following log messages to say that the processing was stopped because of invalid parameter values: 
 
 > LOG_NOTICE: `Request: Set point - point: point10 state: foobar - start`   
 > _Intervening log messages from internal processing_   
-> LOG_ERR: `Request: Set point - point: point10 state: foobar - invalid parameters - abort`   
+> LOG_ERR: `Request: Set point - point: point10 state: foobar - invalid parameter values - abort`   
 
-If the above request forgot to specify the state, i.e., the state parameter is `null`, then the request handler would only generate the following log message to say that the parameter validation failed:
+If the above request forgot to specify the state, i.e., the state parameter is `null`, then the request handler would only generate the following log message to say that the parameter is missing:
 
->  LOG_ERR: `Request: Set point - invalid parameters`
+> LOG_ERR: `Request: Set point - missing parameter state`
+
+And if sending this info to the client failed, the following would be logged:
+
+> LOG_ERR: `Request: Set point - missing parameter state - but sending msg to client failed`