couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Roadmap for the 1.3.0 release
Date Wed, 15 Feb 2012 13:46:36 GMT
I think it's important that the "single instance" mode runs as much,
and preferably all, of the code that a "clustered instance" would run.
Specifically, I would hate to maintain two copies of the httpd
interface (src/couchdb/*httpd*.erl versus chttpd), and really hate to
switch between them at runtime. The scope for surprising regressions
is too great.


On 15 February 2012 13:29, Bob Dionne <> wrote:
> That sounds really neat, a number of folks have asked for such a thing.
> Right, the ddocs, validation funs, etc.. currently aren't stored globally, which requires
clustered calls to retrieve them
> On Feb 15, 2012, at 8:21 AM, Benoit Chesneau wrote:
>> On Wed, Feb 15, 2012 at 2:13 PM, Bob Dionne
>> <> wrote:
>>> On Feb 14, 2012, at 9:22 PM, Brian Mitchell wrote:
>>>> Has there been any discussion around BigCouch integration strategies? It
seems like it would fit the bill for the next undertaking on the general couch side. Does
anyone from Cloudant have a suggestion for the timeline here?
>>> There's been a lot of discussion in #couchdb and #couchdb-dev but little on the
ml. I'm not sure about timeline. There seems to be a lot of issues, most of them minor technical
ones (the type that readily bog down once more than 3 people get involved). BigCouch embeds
couchdb and was architected to be the clustering layer that couchdb lacks, so in that sense
I think we're in pretty good shape.
>>> Ideally we'd have one common code base but it may be that some configuration
of components is done at build time, perhaps driven by 3 types, mobile, single instance, and
>>> Does it make sense to anyone to think of this in the opposite direction, .i.e.
upgrade/enhance BigCouch to the latest couchdb and then call that couchdb 2.0?
>> I was thinking that having a single instance that you could upgrade as
>> a cluster member with just a configuration swicth would be a better
>> plan. With smart rebalancing I could create cluster really
>> dynamically. I understand  that currently it will be hard technically
>> to do that since couch embedded in bigcouch has been modified to get
>> some infos from the cluster (like the design doc, validate func ...)
>> but it's still possible. Not sure if it should happen first, but I
>> really wish we follow this way rather than creating different
>> instances types.
>> - benoît

View raw message