bitcoind ideas | Bitcointalksearch.org

tcatm

sr. member

Activity: 337

Merit: 285

I started work on a patch that adds a CLI:

https://github.com/tcatm/bitcoin/tree/cli

Code:

$ ./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 {address:amount,...} [minconf=1] [comment]\namounts are double-precision floating point numbers","error":null,"id":1}

> stop

Shutdown initiated. Thank you for using Bitcoin!
$

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Steve on April 19, 2011, 12: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...

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).

Steve

hero member

Activity: 868

Merit: 1008

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)

tcatm

sr. member

Activity: 337

Merit: 285

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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

sr. member

Activity: 337

Merit: 285

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

Topic: bitcoind ideas (Read 2054 times)