Re: Roadmap for the 1.3.0 release
On Feb 15, 2012, at 03:22 , 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? Cloudant havent't yet approached Apache CouchDB with anything regarding their announcement. Any other work from mobile builds and the like might be interesting to support. Were there any interesting changes to pull in from the mobile and embedded device ports? Also, I'm not sure where the view engine refactoring work ended up… I'll look at JIRA but maybe there are specific follow-ups to be made here. The biggest one IIRC was the use of emonk instead of an external Spidermonkey for iOS. Maybe we can make that a compile option like ./configure --enable-emonk-view-server so people can choose which one to run. Finally, for our included javascript libraries and Futon runtime, are we going to replace or update anything here? I'd imagine a newer jQuery could be an advantage for those doing CouchApps. Good that you bring this up. There's also other upstream dependencies that we should look at updating and we don't have a process for that, it usually happens whenever a developer feels like it. I haven't thought about this much yet, but maybe update all dependencies could be a todo before a release branch is created? Cheers Jan --
Re: Roadmap for the 1.3.0 release
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? Any other work from mobile builds and the like might be interesting to support. Were there any interesting changes to pull in from the mobile and embedded device ports? Also, I'm not sure where the view engine refactoring work ended up… I'll look at JIRA but maybe there are specific follow-ups to be made here. Finally, for our included javascript libraries and Futon runtime, are we going to replace or update anything here? I'd imagine a newer jQuery could be an advantage for those doing CouchApps. Brian. On Tuesday, February 14, 2012 at 7:28 , Noah Slater wrote: So far we have: https://issues.apache.org/jira/browse/COUCHDB-1410
Re: Roadmap for the 1.3.0 release
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
Re: Roadmap for the 1.3.0 release
On Wed, Feb 15, 2012 at 11:48 AM, Jan Lehnardt j...@apache.org wrote: On Feb 15, 2012, at 03:22 , Brian Mitchell wrote: Any other work from mobile builds and the like might be interesting to support. Were there any interesting changes to pull in from the mobile and embedded device ports? Also, I'm not sure where the view engine refactoring work ended up… I'll look at JIRA but maybe there are specific follow-ups to be made here. The biggest one IIRC was the use of emonk instead of an external Spidermonkey for iOS. Maybe we can make that a compile option like ./configure --enable-emonk-view-server so people can choose which one to run. There is some work started about that in the refuge project using old work done by @davisp used in couchbase and my emonk_helper. I will provide patches asap. Finally, for our included javascript libraries and Futon runtime, are we going to replace or update anything here? I'd imagine a newer jQuery could be an advantage for those doing CouchApps. Good that you bring this up. There's also other upstream dependencies that we should look at updating and we don't have a process for that, it usually happens whenever a developer feels like it. I haven't thought about this much yet, but maybe update all dependencies could be a todo before a release branch is created? +1 for a ticket :) Also include support for mobile support in futon would be fine. (but i think we should only depends on jquery rather than including another framework) . - benoit
Re: Roadmap for the 1.3.0 release
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
Roadmap for the 1.3.0 release
Devs, Please use this thread to discuss roadmap items for the 1.3.0 release. The current hot topic seems to be number handling. We'd like to formalise, improve, and document how we handle numbers. What else? Thanks, N
Re: Roadmap for the 1.3.0 release
So far we have: https://issues.apache.org/jira/browse/COUCHDB-1410 On Tue, Feb 14, 2012 at 12:16 PM, Noah Slater nsla...@tumbolia.org wrote: Devs, Please use this thread to discuss roadmap items for the 1.3.0 release. The current hot topic seems to be number handling. We'd like to formalise, improve, and document how we handle numbers. What else? Thanks, N
Re: Roadmap for the 1.3.0 release
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? Any other work from mobile builds and the like might be interesting to support. Were there any interesting changes to pull in from the mobile and embedded device ports? Also, I'm not sure where the view engine refactoring work ended up… I'll look at JIRA but maybe there are specific follow-ups to be made here. Finally, for our included javascript libraries and Futon runtime, are we going to replace or update anything here? I'd imagine a newer jQuery could be an advantage for those doing CouchApps. Brian. On Tuesday, February 14, 2012 at 7:28 , Noah Slater wrote: So far we have: https://issues.apache.org/jira/browse/COUCHDB-1410
