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 > <dio...@dionne-associates.com> 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
