couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: modular or monolithic: how do you envision Apache CouchDB?
Date Sun, 05 Feb 2012 18:45:44 GMT
On Sun, Feb 5, 2012 at 5:33 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> 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Ʈr

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).

Mime
View raw message