On Sun, Feb 5, 2012 at 5:33 AM, Benoit Chesneau <[email protected]> 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).
