Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qr5Cv-0005KV-6F for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 09:36:13 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.175 as permitted sender) client-ip=209.85.160.175; envelope-from=witchspace81@gmail.com; helo=mail-gy0-f175.google.com; Received: from mail-gy0-f175.google.com ([209.85.160.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qr5Ct-00008Z-1o for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 09:36:13 +0000 Received: by gyg4 with SMTP id 4so686276gyg.34 for ; Wed, 10 Aug 2011 02:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.214.9 with SMTP id m9mr7898908ybg.345.1312968965655; Wed, 10 Aug 2011 02:36:05 -0700 (PDT) Received: by 10.150.52.5 with HTTP; Wed, 10 Aug 2011 02:36:05 -0700 (PDT) Date: Wed, 10 Aug 2011 09:36:05 +0000 Message-ID: From: John Smith To: Bitcoin Dev Content-Type: multipart/alternative; boundary=000e0cd378dccc8c1e04aa236845 X-Spam-Score: 0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (witchspace81[at]gmail.com) 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.5 SF_NO_SPF_SPAM SF_NO_SPF_SPAM -1.4 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Qr5Ct-00008Z-1o Subject: [Bitcoin-development] Change to multiple executables? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 09:36:13 -0000 --000e0cd378dccc8c1e04aa236845 Content-Type: text/plain; charset=ISO-8859-1 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. - 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. - 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. JS --000e0cd378dccc8c1e04aa236845 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

In the current mainline client everything is lugged into one ex= ecutable (with an optional daemon-only one). I think this is a bad idea for= various reasons, and would propose something like:
  • bitcoind: bi= tcoin daemon
  • bitcoin(-qt): bitcoin GUI executable
  • bitcoincl: bitcoin RPC com= mand line
By default, all three would be built. In non-GUI mod= e, only bitcoind and bitcoincl are built (the names are obviously open for = discussion).

Advantages:
  • It is more clear to the user. One command, one f= unction.
  • It simplifies the main functions.
  • The UI would no = longer double-function as daemon. It is a waste of memory to link the UI li= bs if you only want to run a background process.
  • 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?=A0 This would also prevent accidentally launching the daemon/UI l= ocally if you just want to send a command and forget to give an argument.
JS=
--000e0cd378dccc8c1e04aa236845--