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.
B. On 15 February 2012 13:29, Bob Dionne <[email protected]> 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 >> <[email protected]> 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 >
