MIME-Version: 1.0
In-Reply-To: <22CF03CB-7A4B-44D9-8989-22798795BB16@bitsofproof.com>
References: <CABm2gDrApVuxF8DFf32V=pQhDKvvVfcDK=LeCXJ9h9o8CY+wNQ@mail.gmail.com>
	<55B723EA.7010700@voskuil.org>
	<CABm2gDok2gH2R8=x3a8PmPiM56WFg3TKzCum_WS=uV9-T1Ss3g@mail.gmail.com>
	<55B939CF.1080903@voskuil.org>
	<CABm2gDq1wHP01Tncw3hu=SCWQHaAOMjWOVYQWdQsOZ+E7zp9Yw@mail.gmail.com>
	<CABm2gDr_ePfPeWB8pEO8QNHDjUZpybVuCAdDmMxJxMaC8+2bGA@mail.gmail.com>
	<C4EA4A39-1920-4F33-822C-FBD12DF81004@bitsofproof.com>
	<CABm2gDqkF20ZoexQSV8iORb3ukxxZr5RasTLxJqQfSTsTqHvog@mail.gmail.com>
	<3390F712-879A-46E9-ABCD-D35B51190304@bitsofproof.com>
	<CABm2gDpcEmiPNQWeUk5aTjuTSRAJSPYfgAKc7B_qrqw0w04xoA@mail.gmail.com>
	<C486E9D9-D799-48B9-B80F-1A165DFD6536@bitsofproof.com>
	<CABr1YTcx4V0Q4-ZQBEiNG-z1NKeFzxzhMekRN3YRRLz+bme2iw@mail.gmail.com>
	<22CF03CB-7A4B-44D9-8989-22798795BB16@bitsofproof.com>
Date: Sun, 30 Aug 2015 01:30:39 +0200
Message-ID: <CABm2gDrW0hrom2pBavU=6rH5m-+Dhr+NO--_FJ3Co92tT=t45A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Libbitcoin <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin
 Core and hard forks)
Precedence: list

On Sun, Aug 23, 2015 at 8:42 AM, Tamas Blummer <tamas@bitsofproof.com> wrote:
> I see the huge amount of sweat and love that went into core and it actually
> hurts to see that most is expended in friction and lack of a vision for the
> software architecture.
>
> To be concrete, this was my plan if dealing with the Core code base:
>
> 1) I'd consider the separation of networking and storage as suggested for a
> future extended libconsensus low priority, as their design should be (are)
> dominated by the need of the consensus logic only.
>
> 2) create an API to the consensus+networking+storage service that is not at
> the C++ language level but some scaleable cross-platform remoting, like eg.
> ZeroMQ.
> This API should be minimal and simple, assuming that one fully trusts the
> node answering it. This API would unlock user land development by distinct
> teams with diverse technologies.

I plan to replicate the RPC API (or a subset of it) using ZMQ's
req/rep pattern, but #6103 comes first.

> 3) move the wallet, QT and RPC and other backward compatibility stuff (if
> e.g. there is some mining support) in-top of the new API and into distinct
> source code repositories.

Well, the RPC is the API. For libconsensus, its C API is the API.
We've been talking about separating the wallet and qt to a different
repository for long, but modularization is a prerequisite.