couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: compaction plugin, auth handler, foo plugin & couchdb core [resent]
Date Tue, 16 Aug 2011 16:42:23 GMT
On Tue, Aug 16, 2011 at 6:45 AM, Jan Lehnardt <> wrote:
> Hi Benoit,
> thanks for raising this again. I think we have a good plan to get started but
> it wouldn't hurt to get a little more organised. I think the plan is as follows:
> 1. Move to git, this makes all the subsequent steps more easy.
> 2. srcmv, reorganising the source code so we are prepared to do all the things
>    you mention and all the other things we talked about in the past :)
> 3. Profit.
> --
> As for my wish list, all this post the git move:
> We could release 1.2 based off of current trunk + a few of the more
> useful JIRA patches that we haven't committed yet.
> After 1.2.x is branched, srcmv trunk and start the internal refactoring
> and pluginnifying and release 1.3 off that.
> At some point merging between before and after srcmv merging
> patches is going to be a pain, so I'd like to keep that time as short
> as possible and thus keep the differences between 1.2 and 1.3 (given
> that these are the border cases) as small as possible.
> Cheers
> Jan
> --

Early morning pre-caffeine but this sounds like a pretty good idea to
my addled brain.

> On Aug 16, 2011, at 1:20 PM, 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