Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 173.246.101.161 as permitted sender)
	client-ip=173.246.101.161;
	envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; 
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 10 Aug 2011 12:14:49 +0200
Message-ID: <1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Change to multiple executables?
Precedence: list

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