couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: modular or monolithic: how do you envision Apache CouchDB?
Date Mon, 06 Feb 2012 02:41:30 GMT
On Sun, Feb 5, 2012 at 3:33 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> 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
>

Patches are welcome. of course. but I don't see how it's related to this topic.

Anyway I didn't speak about git or rebar at that point. However it
seems important for me that modules could be removed easily from a
final release and that the distributor don't have to distribute it
with useless code.

Having modules managed as standalone projects offer different advantages:
- history could be managed apart, an it's a lot easier to merge/rebase
etc by doing this.
- removing a module (code and binary) is just a matter of "not
including it in the release"
- modules are really optional.

About using different modules with the core to provide a release, i
don't see where is the real problem. The way to test integration could
be easily managed imo. As far as i know it's a matter of process.
Speaking about bigcouch I can feel the pain, but that's mostly because
the process isn't strict as it can be, and indeed some modules aren't
really modules in bigcouch case. I can see in that case bigcouch as
couch+fabric+mem3 = 1 core app, while chttpd, view, rexi, and maybe
the attachment service could be standalone apps if they can works as
standalone app (rexi) or replaced (chttpd,  view server).

And we could do that for couch too.

- benoƮt

Mime
View raw message