Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

["Jorge Timón" <jtimon@jtimon.cc>]

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.