Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qr5zg-00065E-FX for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 10:26:36 +0000 Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qr5zf-0008Jp-NE for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 10:26:36 +0000 Received: by gyg4 with SMTP id 4so704670gyg.34 for ; Wed, 10 Aug 2011 03:26:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.31.13 with SMTP id e13mr7928922ybe.174.1312971990141; Wed, 10 Aug 2011 03:26:30 -0700 (PDT) Received: by 10.150.52.5 with HTTP; Wed, 10 Aug 2011 03:26:30 -0700 (PDT) In-Reply-To: <1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me> References: <1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me> Date: Wed, 10 Aug 2011 10:26:30 +0000 Message-ID: From: John Smith To: Matt Corallo Content-Type: multipart/alternative; boundary=000e0cd35788128d4404aa241df3 X-Spam-Score: 2.0 (++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -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) -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.7 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: bluematt.me] 1.5 SF_NO_SPF_SPAM SF_NO_SPF_SPAM -1.9 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Qr5zf-0008Jp-NE Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [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 10:26:36 -0000 --000e0cd35788128d4404aa241df3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 10, 2011 at 10:14 AM, Matt Corallo wrote: > 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. > UI would obviously still have RPC functionality with -server. I don't mean dropping that. The UI links both the UI and the network code (for now, until this is separated out and the preferred UI<->core communication method is through RPC). I just mean that the *headless* daemon is separate from the UI executable, which is the case for any other sane client/server-based program in existence, from bittorrent nodes to game servers. It would also make it possible to build the command line RPC client (bitcoin-cl) *without* building the server or UI. Useful if you want to remotely control a Bitcoin daemon but not want to build it locally. JS --000e0cd35788128d4404aa241df3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 10, 2011 at 10:14 AM, Matt Coral= lo <bitcoi= n-list@bluematt.me> wrote:
I would argue its less clear for the user. =A0Instead of opening either
bitcoind or bitcoin to get RPC or GUI, now you have to open bitcoin and
bitcoind or bitcoincl and bitcoind. =A0Now, obviously bitcoin and
bitcoincl can open bitcoind for you, but I think adding more executables complicates things for little clear advantage.

UI = would obviously still have RPC functionality with -server. I don't mean= dropping that. The UI links both the UI and the network code (for now, unt= il this is separated out and the preferred UI<->core communication me= thod is through RPC).

I just mean that the *headless* daemon is separate from the UI executab= le, which is the case for any other sane client/server-based program in exi= stence, from bittorrent nodes to game servers.

It would also make it= possible to build the command line RPC client (bitcoin-cl) *without* build= ing the server or UI. Useful if you want to remotely control a Bitcoin daem= on but not want to build it locally.

JS

--000e0cd35788128d4404aa241df3--