On Sun, May 25, 2014 at 1:24 AM, Eric Voskuil <eric@???> wrote:
> When it comes down to it a repo is a completely arbitrary boundary. What
> matters to the organization above is that the 5 libraries above can be
> deployed independently. Considering interlib dependencies there are five
> deployment scenarios:
>
> libbitcoin
> libbictoin_client->libbitcoin
> libbictoin_wallet->libbitcoin
> libbitcoin_node->libbitcoin
> libbitcoin_server->libbitcoin_node->libbitcoin

Yes, this is the important thing. It should be possible to build the
minimal system for a particular use case. If somebody is just doing
offline data manipulation, they shouldn't need anything more than
libbitcoin. If they are doing a wallet, they probably want
libbitcoin_client and libbitcoin_wallet, but not libbitcoin_server. On
the flip side, somebody doing a server probably doesn't want
libbitcoin_client or libbitcoin_wallet. A site like blockchain.info
would just need libbitcoin_client and not libbitcoin_wallet. I'm sure
there are many other meaningful combinations.

On the other hand, I don't see the need for full independence.
Assuming we can individually enable and disable each orthogonal piece
of functionality, I don't care if we have a common build system, or if
we share general project things like "define.hpp" or BC_API. So long
as we end up with a pile of separate .dll or .so files at the end of
the day, I am happy.

> This factoring is designed in part to isolate dependencies so that they
> don't get unnecessarily dragged into deployments. This is really the big
> issue. My main concern would be that without strong isolation we will
> have to be very watchful for dependency creep, even between the
> libbitcoin libs themselves.

Right, this is a problem. If we do meld the repos, and build systems,
we have to be sure that people are compiling the libs independently on
a regular basis. Otherwise, people might accidentally introduce
entanglements without noticing.

Maybe there is a way to get the best of both worlds, were we have a
unified repository and build system, but people still get errors if
they try to use functionality or headers from other parts of the lib
they don't depend on.

> Another benefit to the library/repo alignment we have planned is that it
> makes the toolkit very approachable to the newcommer. When one looks at
> bitcoin (core) there is one repo, it looks like a monolith (and it is).
> Even so new work has recently been taken on outside of that repo
> (secp256k1). Imagine trying to do that within the bitcoin repo, and
> imagine forking bitcoin to work with secp256k1.

I would actually argue this the other way - the separate repos make
the project very unfriendly for newcomers. First of all, just getting
the system set up involves cloning and building a bunch of separate
repos. We have a shell script to help with the task, but that's more
for users, not developers. As a developer, I still have to clone and
build each repo by hand.

Then, assuming you actually have a working baseline, working with the
separate repos is annoying. I spend a lot of time just trying to keep
things in sync, as people change things in one part of the library
that affect the others. For example, to implement my uri parser, I had
to create an "is_base58" function in the libbitcoin core library. This
actually led to a bug report, as somebody updated libwallet without
realizing they need to update libbitcoin as well.

That's just a simple example of adding a single function to the core.
Imagine how hard it was to do big cross-repo refactorings like the
endianness changes and the secp256k1 integration.

> Merging the repos wouldn't really change this situation. If we
> consequently merged the defines we would then lose the ability to treat
> the libraries independently. This is actually an example of the subtle
> entanglements that we would have to be very watchful for.

I don't think this matters. What's important is the ability to trim
out unneeded pieces of functionality, not build-level independence.

-William