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; 
MIME-Version: 1.0
In-Reply-To: <1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me>
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
	<1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me>
Date: Wed, 10 Aug 2011 10:26:30 +0000
Message-ID: <CAJNQ0stFevVgfwBuXkJKJ_mJsEuogOPyHR6U+qVTvpdKjdkd=g@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=000e0cd35788128d4404aa241df3
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Precedence: list

--000e0cd35788128d4404aa241df3
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Aug 10, 2011 at 10:14 AM, Matt Corallo <bitcoin-list@bluematt.me>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

<br><div class=3D"gmail_quote">On Wed, Aug 10, 2011 at 10:14 AM, Matt Coral=
lo <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-list@bluematt.me">bitcoi=
n-list@bluematt.me</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
>
I would argue its less clear for the user. =A0Instead of opening either<br>
bitcoind or bitcoin to get RPC or GUI, now you have to open bitcoin and<br>
bitcoind or bitcoincl and bitcoind. =A0Now, obviously bitcoin and<br>
bitcoincl can open bitcoind for you, but I think adding more executables<br=
>
complicates things for little clear advantage.<br></blockquote><div><br>UI =
would obviously still have RPC functionality with -server. I don&#39;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&lt;-&gt;core communication me=
thod is through RPC).<br>
<br>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.<br><br>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.<br>
<br>JS<br><br></div></div>

--000e0cd35788128d4404aa241df3--