couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject compaction plugin, auth handler, foo plugin & couchdb core [resent]
Date Tue, 16 Aug 2011 11:20:51 GMT
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

Mime
View raw message