|
tcatm (OP)
|
 |
April 19, 2011, 03:33:26 PM |
|
Some ideas for bitcoind:
* rename bitcoind -> bitcoin-cli
* add an interactive readline RPC interface forking is disabled
* don't start TCP RPC by default if forking is disabled
Examples:
$ bitcoin-cli
> getinfo
{...}
> stop
$
$ bitcoin-cli -server
Starting ThreadRPC
> stop
$
$ bitcoin-cli -daemon
$ # same behaviour as bitcoind
|
|
|
|
|
|
|
|
|
|
You can see the statistics of your reports to moderators on the "Report to moderator" pages.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
Luke-Jr
Legendary
 Offline
Activity: 2576
Merit: 1186
|
|
April 19, 2011, 04:00:10 PM |
|
Sounds like a good idea, though I think for a real CLI client, output should be formatted for human consumption, not merely pretty-printed JSON.
Why not split bitcoin-cli out from bitcoind? It's not like they share much code (besides the JSON library, which can be dynamically linked as it should be).
|
|
|
|
|
tcatm (OP)
|
|
April 19, 2011, 04:14:28 PM |
|
Good idea. Maybe the stdio CLI could accept JSON or RPC commands? JSON returns JSON, RPC prettyprints.
So a client like Spesmilo could just start bitcoin-cli as a subprocess and communicate via a pipe.
At the same time, bitcoin-cli could function as an interactive client to another bitcoin(-cli) running with -server.
|
|
|
|
|
|
Steve
|
|
April 19, 2011, 05:50:25 PM |
|
I mentioned it on IRC that I don't see a need for bitcoind to have any process forking behavior in it...interactively, you can fork the process easy enough to run in the background (and even detach it after starting). And, if you're setting up a server, it's simple enough to run in the background (and if you're serious, you'll be using something along the lines of daemontools to manage it).
I could even be persuaded that the only command I/O interface it needs to support is over stdio (because that too is easy enough to redirect, could be put behind something like xinetd, etc). Switches could be used to control whether it's JSON, or human readable, etc (or use separate executables for different formats). (but there's also an argument to be made against over-doing the modularity)
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
April 19, 2011, 08:27:06 PM |
|
I mentioned it on IRC that I don't see a need for bitcoind to have any process forking behavior in it... Disagree. What if startup fails? Forking after startup has succeeded allows one to not only know if there was a problem, but also block until the server is running (and can therefore know a connect will immediately succeed). |
|
|
|
|
tcatm (OP)
|
|
April 30, 2011, 03:20:54 AM |
|
I started work on a patch that adds a CLI: https://github.com/tcatm/bitcoin/tree/cli$ ./bitcoind
Welcome to Bitcoin, the digital crypto currency. (0.3.22-beta)
Type: 'help' for help with commands
'stop' to quit
> getinfo
{"result":{"version":32200,"balance":1.64048576,"blocks":120928,"connections":1,"proxy":"","generate":false,"genproclimit":1,"difficulty":92347.59095209,"hashespersec":0,"testnet":false,"keypoololdest":2465843123,"paytxfee":0.00000000,"errors":""},"error":null,"id":1}
> help sendmany
{"result":"sendmany <fromaccount> {address:amount,...} [minconf=1] [comment]\namounts are double-precision floating point numbers","error":null,"id":1}
> stop
Shutdown initiated. Thank you for using Bitcoin!
$
|
|
|
|
|
|
