1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1Qr5oR-00070L-C7
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 10:14:59 +0000
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;
Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Qr5oQ-0001GC-EL for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 10:14:59 +0000
Received: from [192.168.0.10] (i59F7664C.versanet.de [89.247.102.76])
by mail.bluematt.me (Postfix) with ESMTPSA id EE93B2B54
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Aug 2011 12:14:35 +0200 (CEST)
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
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.3 (--)
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 SPF_PASS SPF: sender matches SPF record
-0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Qr5oQ-0001GC-EL
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2011 10:14:59 -0000
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
|
