Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-10 🗒️ Summary of this message: Proposal to ...
📅 Original date posted:2011-08-10
🗒️ Summary of this message: Proposal to split Bitcoin client into separate executables for daemon, GUI, and RPC command line. Advantages include clearer functions and simplified main functions.
📝 Original message:On Wed, 2011-08-10 at 09:36 +0000, John Smith wrote:
> All,
>
> In the current mainline client everything is lugged into one
> executable (with an optional daemon-only one). I think this is a bad
> idea for various reasons, and would propose something like:
> * bitcoind: bitcoin daemon
> * bitcoin(-qt): bitcoin GUI executable
> * bitcoincl: bitcoin RPC command line
> By default, all three would be built. In non-GUI mode, only bitcoind
> and bitcoincl are built (the names are obviously open for
> discussion).
>
> Advantages:
> * It is more clear to the user. One command, one function.
I would argue its less clear for the user. Instead of opening either
bitcoind or bitcoin to get RPC or GUI, now you have to open bitcoin and
bitcoind or bitcoincl and bitcoind. Now, obviously bitcoin and
bitcoincl can open bitcoind for you, but I think adding more executables
complicates things for little clear advantage.
> * It simplifies the main functions.
> * The UI would no longer double-function as daemon. It is a
> waste of memory to link the UI libs if you only want to run a
> background process.
As you pointed out, we have bitcoind for just this reason.
> * The UI and daemon would no longer double-function as RPC call.
> Why load the code for UI and network if you just want to send
> a single command over JSONRPC? This would also prevent
> accidentally launching the daemon/UI locally if you just want
> to send a command and forget to give an argument.
Making RPC optional for GUI users would be an interesting addition.
> JS
All this said, I totally agree with the more clear split of the source
into separate library-ish components (I'm working on part of that now).
However, I don't like the idea of splitting into more executables.
If you are suggesting this so that bitcoin-qt can be distributed being
built off of bitcoind, I would say go ahead and pull-request bitcoin-qt.
I'm of the opinion that it should be merged whether we have autotools or
not (we already have 5 makefiles, whats a few more options in those?)
and jgarzik seemed to indicate that he would agree (Gavin?, sipa?
tcatm?).
Matt
🗒️ Summary of this message: Proposal to split Bitcoin client into separate executables for daemon, GUI, and RPC command line. Advantages include clearer functions and simplified main functions.
📝 Original message:On Wed, 2011-08-10 at 09:36 +0000, John Smith wrote:
> All,
>
> In the current mainline client everything is lugged into one
> executable (with an optional daemon-only one). I think this is a bad
> idea for various reasons, and would propose something like:
> * bitcoind: bitcoin daemon
> * bitcoin(-qt): bitcoin GUI executable
> * bitcoincl: bitcoin RPC command line
> By default, all three would be built. In non-GUI mode, only bitcoind
> and bitcoincl are built (the names are obviously open for
> discussion).
>
> Advantages:
> * It is more clear to the user. One command, one function.
I would argue its less clear for the user. Instead of opening either
bitcoind or bitcoin to get RPC or GUI, now you have to open bitcoin and
bitcoind or bitcoincl and bitcoind. Now, obviously bitcoin and
bitcoincl can open bitcoind for you, but I think adding more executables
complicates things for little clear advantage.
> * It simplifies the main functions.
> * The UI would no longer double-function as daemon. It is a
> waste of memory to link the UI libs if you only want to run a
> background process.
As you pointed out, we have bitcoind for just this reason.
> * The UI and daemon would no longer double-function as RPC call.
> Why load the code for UI and network if you just want to send
> a single command over JSONRPC? This would also prevent
> accidentally launching the daemon/UI locally if you just want
> to send a command and forget to give an argument.
Making RPC optional for GUI users would be an interesting addition.
> JS
All this said, I totally agree with the more clear split of the source
into separate library-ish components (I'm working on part of that now).
However, I don't like the idea of splitting into more executables.
If you are suggesting this so that bitcoin-qt can be distributed being
built off of bitcoind, I would say go ahead and pull-request bitcoin-qt.
I'm of the opinion that it should be merged whether we have autotools or
not (we already have 5 makefiles, whats a few more options in those?)
and jgarzik seemed to indicate that he would agree (Gavin?, sipa?
tcatm?).
Matt