In one of PRs the CLI was completely removed as it was completely obsolete and it was hard to support without proper vision.
That issue aims to revisit what CLI should do and how.
So the main usage of CLI is to be able to run locally some automation and submit tasks (potentially) to the topology and wait for result.
So, the CLI should be able to run Kotlin programs within specific environment. REPL is not the goal -- it can be done via regular kotlinc, however worth later on provide instructions.
By default CLI runs locally within single threaded environment, to run it in distributed mode within the same JVM instance
wavebeans-cli --overseer local --execute-file /path/to/file/even/somewhere/on/internet
Later on should be able to specify remote Overseer.
It might be useful to generate stream output to standard output. For such purpose need to add a new stdout:// protocol in output specification. The only caveat here is, the control over how much outputs are specified is fully on the user.
Performance
To measure performance of the executed code you may ask to output performance metrics:
Some of the streams are infinite and needs to be stopped manually. Or even stop processing earlier finite streams. Gracefully.
Handle ^C properly -- the first time user pressed it should start gracefully terminate the processing, the second time it should forcefully stop the execution regardless of result.
In one of PRs the CLI was completely removed as it was completely obsolete and it was hard to support without proper vision.
That issue aims to revisit what CLI should do and how.
So the main usage of CLI is to be able to run locally some automation and submit tasks (potentially) to the topology and wait for result.
So, the CLI should be able to run Kotlin programs within specific environment. REPL is not the goal -- it can be done via regular kotlinc, however worth later on provide instructions.
Functionality
Command line parameters
Running
To evaluate file
To evaluate Kotlin code as an input string
By default CLI runs locally within single threaded environment, to run it in distributed mode within the same JVM instance
Later on should be able to specify remote Overseer.
It might be useful to generate stream output to standard output. For such purpose need to add a new
stdout://
protocol in output specification. The only caveat here is, the control over how much outputs are specified is fully on the user.Performance
To measure performance of the executed code you may ask to output performance metrics:
To measure time:
It'll output something like this:
Interrupting execution
Some of the streams are infinite and needs to be stopped manually. Or even stop processing earlier finite streams. Gracefully.
Handle
^C
properly -- the first time user pressed it should start gracefully terminate the processing, the second time it should forcefully stop the execution regardless of result.