couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
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 <jan@apache.org> 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] 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