couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Dionne <>
Subject Re: Roadmap for the 1.3.0 release
Date Wed, 15 Feb 2012 13:29:49 GMT
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 clustered
>> 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