From dev-return-20464-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sun Feb 5 18:46:54 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8D8DB9D90 for ; Sun, 5 Feb 2012 18:46:54 +0000 (UTC) Received: (qmail 77885 invoked by uid 500); 5 Feb 2012 18:46:53 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 77800 invoked by uid 500); 5 Feb 2012 18:46:53 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 77792 invoked by uid 99); 5 Feb 2012 18:46:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Feb 2012 18:46:52 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.220.180 as permitted sender) Received: from [209.85.220.180] (HELO mail-vx0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Feb 2012 18:46:45 +0000 Received: by vcbfo1 with SMTP id fo1so4655814vcb.11 for ; Sun, 05 Feb 2012 10:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=Y+pG1SQ/aOMgSMVuxSVkrUQAMrCYwT4beCKWdq/C+CU=; b=xqpFOb6IWWq5g7QFiND6+noCVQTgyeYA1zwKY4sDtKZTFARLEEfRto/26Ow0waINZ3 NSr/2grgyG/6/zvvFW9DxF+3gRw6h/tRs5z8cDru1he32f+qdjCiW7qsiuK3OLsPUI4u esGMNvSsvcEJLxI2caMq1rsCaWDlkiIwG9130= Received: by 10.220.224.136 with SMTP id io8mr8017942vcb.4.1328467584419; Sun, 05 Feb 2012 10:46:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.188.1 with HTTP; Sun, 5 Feb 2012 10:45:44 -0800 (PST) In-Reply-To: References: From: Paul Davis Date: Sun, 5 Feb 2012 18:45:44 +0000 Message-ID: Subject: Re: modular or monolithic: how do you envision Apache CouchDB? To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Sun, Feb 5, 2012 at 5:33 AM, Benoit Chesneau 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=EEr I think there are a couple issues here that are intertwined that need not b= e. 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).