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
