public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <bitcoin-list@bluematt•me>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Date: Wed, 10 Aug 2011 12:14:49 +0200	[thread overview]
Message-ID: <1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me> (raw)
In-Reply-To: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>

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




  reply	other threads:[~2011-08-10 10:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10  9:36 John Smith
2011-08-10 10:14 ` Matt Corallo [this message]
2011-08-10 10:26   ` John Smith
2011-08-10 10:43   ` Pieter Wuille
     [not found]     ` <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
2011-08-10 13:18       ` John Smith
2011-08-10 16:49         ` Gavin Andresen
2011-08-10 17:45           ` John Smith
2011-08-10 18:41             ` Gavin Andresen
2011-08-10 19:32               ` Andy Parkins
2011-08-10 19:57                 ` Jeff Garzik
2011-08-10 21:13                   ` Andy Parkins
2011-08-10 21:35                     ` Jeff Garzik
2011-08-10 22:38                       ` Andy Parkins
2011-08-11  3:20                         ` Jeff Garzik
2011-08-11  5:47                           ` Andy Parkins
2011-08-11 11:45                             ` Joel Joonatan Kaartinen
2011-08-11 12:01                               ` Christian Decker
2011-08-11 14:04                               ` Andy Parkins
2011-08-11 12:11                     ` Mike Hearn
2011-08-11 13:51                       ` Andy Parkins
2011-08-11 12:19               ` John Smith
2011-08-11 13:08                 ` Pieter Wuille
2011-08-10 18:43             ` Luke-Jr
2011-08-10 19:48               ` Jeff Garzik
2011-08-10 21:37 ` Jeff Garzik
2011-08-11 13:50 ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me \
    --to=bitcoin-list@bluematt$(echo .)me \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox