Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.210.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YCSe357hzbtR4egi1z=BynoJq_FX8hQ80F98QqyS_33jA@mail.gmail.com>
References: 
 <CAJNb-9pU-A-6WLjTt0MM+Fic3ySCnc2uzs3P4Nt9P8MbAAySXQ@mail.gmail.com>
	<CAJ_m3YCSe357hzbtR4egi1z=BynoJq_FX8hQ80F98QqyS_33jA@mail.gmail.com>
Date: Sun, 5 Feb 2012 15:33:41 -0800
Message-ID: 
 <CAAL6JQi3PXLOaV8JHz_d_K7k+tE72+OVofSknuYGg957URDEmQ@mail.gmail.com>
Subject: Re: modular or monolithic: how do you envision Apache CouchDB?
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree with Paul that modularity is not tightly bound to git
structure. I'm fine to not break out the git structure into multiple
repos, and would maybe even prefer it. The main advantage of doing it
would be to merge commits from external projects that decide to pull
in individual CouchDB components, but that's possible to do in the
monolithic setup, too. Not white belt git-fu, but it certainly isn't
dan-level.

If there are components in the Apache CouchDB repo which are optional,
or can be made optional, patches welcome for turning them off at build
time.

I am 100% for breaking apart the various modules, though. Code
organization would benefit greatly, as well as the possibility for
transclusion of components into other projects.

-R

On Sun, Feb 5, 2012 at 10:45, Paul Davis <paul.joseph.davis@gmail.com> wrot=
e:
> On Sun, Feb 5, 2012 at 5:33 AM, Benoit Chesneau <bchesneau@gmail.com> wro=
te:
>> Hi,
>>
>> Last day we had a quick discussion on IRC about splitting code in
>> different apps or not. I wasn't totally crystal clear about my position
>> and I would like to clarify it a little. Imo everything turn around the
>> question , "how do you envision Apache CouchDB".
>>
>> It appears for me that some wants to distribute it as a full product,
>> everything is embedded in one archive. In that case the distributiuon
>> system is only targeting this goal and nothing in the core allows
>> alternatives.
>>
>> While I'm agree we should offer a "canonical" release of Apache CouchDB,
>> I'm thinking more Apache CouchDB as a collections of modules with a
>> core. For example CouchDB could be:
>>
>> a k/v server that can live on one or more machine : the core
>> with an HTTP api
>> with a M/R api also accessible with HTT
>> with a _changes API
>> with a replicaton API
>> with a couchapp engine
>> with javascript support
>>
>> So anyone can eventually replace, remove or add a module in its own
>> couchdb distribution. The release system could also be enough smart to
>> allws a distributor to customize its own couchdb.
>>
>> What do you think about it? How do you envision CouchDB ?
>>
>> - beno=C3=AEr
>
> I think there are a couple issues here that are intertwined that need not=
 be.
>
> First, I don't think that having code in multiple apps is necessarily
> incompatible with having the code in a single repository. BigCouch was
> split out into multiple repositories with one Git repo per app and I
> can't say that I'm a fan. There are definitely arguments for it, but I
> find coordinating merges and pull requests across multiple git repos
> as well as the extra difficulty in preparing single tarball source
> releases to be a bigger negative than the nominal benefit of making
> sure changes to apps are in separate commits (and the perceived
> benefit that this forces less coupling).
>
> Secondly, the idea of allowing users/packagers to customize what
> modules are included in the "canonical" CouchDB seems like its just
> going to open up a world of hurt. If part of the promise of CouchDB is
> "run anywhere" then having things out there called "CouchDB" that
> don't include basic functionality like m/r views and _changes feeds is
> going to cause a lot of breakage.
>
> That said, I think that there definitely is a use case for making
> CouchDB more modular such that advanced Erlang uses are possible. I
> think we should have our code modularized internally so that it's
> possible (and much much easier) for Erlangers to pull just a KV core
> if they want. The distinction here is that people that just want to
> pull specific modules don't call their end result "CouchDB". Now, this
> may require some effort to integrate directly into tools like rebar,
> but I view this as a secondary goal that shouldn't interfere with our
> primary mission of releasing "CouchDB".
>
> Or, more succinctly, "CouchDB" should be what is built from our source
> release/repo but we should make it possible for people to reuse parts
> of CouchDB (as long as they don't call their end result CouchDB to
> avoid user confusion).