couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: compaction plugin, auth handler, foo plugin & couchdb core [resent]
Date Tue, 16 Aug 2011 11:25:36 GMT
+1 on splitting into more focused and OTP compliant applications.
Separating core from httpd in particular.

Sent from my iPhone

On 16 Aug 2011, at 12:21, Benoit Chesneau <> wrote:

> Hi devs;
> Today I see lot of interesting things coming in CouchDB, but also lot of
> different interests and different usages.  Sometimes you need to extend
> couch for your usage. But today if you except the current work on the
> view engine by paul, the couchdb code become more and more monolithic or
> an aggregation of code adding some specific features/changes, while not
> envisioning what could be done by others. Also the way you have to
> extend couchdb make it difficult today to use/merge/... different forks
> around like the one done by cloudant, couchbase and even mine in
> refuge/upondata probably some others too). Couch core should be
> lighter and more open (in its strict sense).
> For example today, http layer(?), replicator(?), proxy, external
> daemons, couchapp engine, rewriter, vhosts, compaction daemon, some auth
> handler could be available as plugins. couch_config could be more
> generic and not relying on an ini file. More specifically we could have
> a couch core looking more like a mnesia alternative, the couchdb
> application, which could be couch core + plugins, distributed as a
> standalone app (like couchdb is actually). This would also maybe allow
> cloudant, couchbase and other to reuse the same core rather than forking
> it while adding their own plugins. Official Plugins could also be
> maintained as standalone projects maybe.
> I wish we could concentrate on that topic for 2.0x and make it a
> priority. That would imply to define what is the couch core, split the
> code [1] and what is a plugin [2]. Maybe the couchdb app can also be a
> full erlang release [3] built with autotools. I think that this
> plugabble structure should be done for example before adding any new
> daemon like the compaction daemon. Don't get me wrong I really like the
> idea to have a default compaction daemon in the couchdb app, and this is
> just an example. But I also want the possibility to add mine working
> differently (or not) and this should be done for the default couchdb
> release, couch core imo should be more neutral.
> Maybe we could start by opening tickets about different tasks to track
> them? What is blocking the split currently since the 1.0.3 is out? Do
> we wait for the svn-to-git conversion?
> - benoƮt
> [1]
> [2]
> [3]

View raw message