Currently if you want to load a machine + advance states or inspect states its state once + store the machine, you always need to spawn a jsonrpc-remote-cartesi-machine beforehand, this make it's usability a bit more complex, we could improve this.
Possible solutions
There are some possible solutions for this:
cartesi-machine could spawn jsonrpc-remote-cartesi-machine on its own and close it, abstracting away the need for the user to explicitly invoke jsonrpc-remote-cartesi-machine
We could allow the cartesi-machine cli to work in a "single shot" mode, where it can only do one advance/inspect state and then close immediately because there is no support for rollback the state. This would need many adjustments and checks in the cartesi-machine.lua.
Local machines could support snapshot/rollback, to have this we could implement a dumb fork() method that duplicates the whole machine state. This would make remote cartesi machines not needed to use the cli in most situations. In the future this fork could be improved to maybe be more performant. I am in favor of doing this way, because it would also allow cloning machines in environments where network stack is not available (e.g. WASM).
Context
Currently if you want to load a machine + advance states or inspect states its state once + store the machine, you always need to spawn a
jsonrpc-remote-cartesi-machinebeforehand, this make it's usability a bit more complex, we could improve this.Possible solutions
There are some possible solutions for this:
cartesi-machinecould spawnjsonrpc-remote-cartesi-machineon its own and close it, abstracting away the need for the user to explicitly invokejsonrpc-remote-cartesi-machinecartesi-machinecli to work in a "single shot" mode, where it can only do one advance/inspect state and then close immediately because there is no support for rollback the state. This would need many adjustments and checks in thecartesi-machine.lua.