+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 <[email protected]> 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] https://github.com/davisp/couchdb-srcmv > [2] https://issues.apache.org/jira/browse/COUCHDB-1012 > [3] http://www.erlang.org/doc/design_principles/release_structure.html
