Re: CouchOne + Membase = Couchbase
Good luck!cheers Mahesh Paolini-Subramanya | CTO |mah...@aptela.com|703.386.1500 Ext. 91002250 Corporate Park Drive | Suite 150| Herndon, VA |www.aptela.comCheck out ourBlog|Follow us onTwitter|Refer aFriend On Feb 8, 2011, at 2:41 AM, Dirkjan Ochtman wrote:Congratulations to all of you!On Tue, Feb 8, 2011 at 07:41, Jan Lehnardt j...@apache.org wrote:Instead of dwelling on the merger or technology, I'd like to address likely questions about the relationship between Couchbase and Apache CouchDB. It is simple, really: at CouchOne we were 100% committed on the Open Source side of things and at Couchbase we will continue to do so at the same degree. In terms of organisation, Couchbase will be it's own independent Open Source project that has Apache CouchDB and memcached as dependencies, but adds a few things of its own that warrant being its own project. Our combined engineering team, led by Damien, will continue to contribute to Apache CouchDB in the same way as we've been to date, only more. I can't wait to share with you what we'll come up with :)And thanks for this summary of the technical side of things.Cheers,Dirkjan
Re: CouchOne + Membase = Couchbase
On Tue, Feb 8, 2011 at 7:41 AM, Jan Lehnardt j...@apache.org wrote: Dear CouchDB folks, developers, users, I don't usually post business-y things here, but I think this one warrants an email. I'm excited to announce that CouchOne, the company Damien, J Chris and I founded in late 2009, is merging with the company Membase to become Couchbase. Together we will be developing a product, also called Couchbase, that is based on CouchDB and Membase / memcached technology. Our goal is to build a simple, fast and elastic database that's gonna kick some ass. I'll leave the details of that for you to read on the websites we've put up — start here: http://www.couchbase.com/ Instead of dwelling on the merger or technology, I'd like to address likely questions about the relationship between Couchbase and Apache CouchDB. It is simple, really: at CouchOne we were 100% committed on the Open Source side of things and at Couchbase we will continue to do so at the same degree. In terms of organisation, Couchbase will be it's own independent Open Source project that has Apache CouchDB and memcached as dependencies, but adds a few things of its own that warrant being its own project. Our combined engineering team, led by Damien, will continue to contribute to Apache CouchDB in the same way as we've been to date, only more. I can't wait to share with you what we'll come up with :) Thanks everybody for your support, past and future. The CouchDB community is by far my favourite and I hope you will accept Couchbase as a new member of this community :) If you have any questions, please feel free to contact me privately, but I'd like to avoid highjacking the list for this thread. Cheers Jan -- http://couchbase.com/ That's good news for couchone, congrats! - benoît
[jira] Commented: (COUCHDB-963) Erlang processes crash when running the delayed_commits test on Windows Server 2008
[ https://issues.apache.org/jira/browse/COUCHDB-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991847#comment-12991847 ] Dave Cottlehuber commented on COUCHDB-963: -- Also replicated, EC2 large instance, w2008 r1sp2 datacenter ed. My reading is that this is an erlang vm problem. Not all restarts fail: [Tue, 08 Feb 2011 08:16:25 GMT] [info] [0.362.0] 125.236.236.206 - - 'POST' /_restart 200 [Tue, 08 Feb 2011 08:16:27 GMT] [info] [0.398.0] Apache CouchDB has started on http://0.0.0.0:5984/ but others do - 7 minute delay is my manual restart coming in: [Tue, 08 Feb 2011 08:23:37 GMT] [debug] [0.2056.0] 'POST' /_restart {1,1} Headers: [{'Accept',application/json}, {'Accept-Charset',ISO-8859-1,utf-8;q=0.7,*;q=0.7}, {'Accept-Encoding',gzip, deflate}, {'Accept-Language',en-us,en;q=0.5}, {'Cache-Control',no-cache}, {'Connection',keep-alive}, {'Content-Length',0}, {'Content-Type',application/json; charset=UTF-8}, {'Cookie',AuthSession=}, {'Host',ec2-204-236-204-144.compute-1.amazonaws.com:5984}, {'Keep-Alive',115}, {'Pragma',no-cache}, {'Referer',http://ec2-204-236-204-144.compute-1.amazonaws.com:5984/_utils/couch_tests.html?script/couch_tests.js}, {'User-Agent',Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10}] [Tue, 08 Feb 2011 08:23:37 GMT] [debug] [0.2056.0] OAuth Params: [] [Tue, 08 Feb 2011 08:23:37 GMT] [info] [0.2056.0] 125.236.236.206 - - 'POST' /_restart 200 [Tue, 08 Feb 2011 08:30:30 GMT] [info] [0.34.0] Apache CouchDB has started on http://0.0.0.0:5984/ So it looks as if couchdb shuts down cleanly through;: handle_restart_req(#httpd{method='POST'}=Req) - couch_httpd:validate_ctype(Req, application/json), ok = couch_httpd:verify_is_server_admin(Req), couch_server_sup:restart_core_server(), which is short sweet: restart_core_server() - init:restart(). leaving couch now into (I think) the vm: restart() - init ! {stop,restart}, ok. Erlang processes crash when running the delayed_commits test on Windows Server 2008 --- Key: COUCHDB-963 URL: https://issues.apache.org/jira/browse/COUCHDB-963 Project: CouchDB Issue Type: Bug Components: Infrastructure Affects Versions: 1.0.1 Environment: This Windows box is a virtual machine Windows Server 2008 Standard without Hyper-V Service Pack 2 64-bit 2 GB RAM 2 Core Intel Xeon CPU @ 2.53GHz each Reporter: Terry Smith Attachments: Apache CouchDB.debug.2, couch.log The debugging I've done points to this being an erlsrv.exe bug. Here my steps to recreate. Install 1.0.1 CouchDB as a service using the Windows Binary Installer. I did not select to Start service after installation. Edit the local.ini to set the logging level to debug. Go to the service control panel and start the Apache CouchDB service. Go to Test Suite in Futon and run the delayed_commits test. After about 15 - 20 seconds go to the service control panel and refresh to see that the service is no longer running. ProcessExplorer verifies the erlsrv.exe and erl.exe processes are not running. The last message in the log is a _restart command that returns 200. When I run CouchDB using CouchDB.bat. The test completes without crashing. When I set the DebugType in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Ericsson\Erlang\ErlSrv\1.1\Apache CouchDB to 1 (DEBUG_TYPE_NEW) to get a erlsrv.exe log, the test completes without crashing. I will attach the log files from CouchDB and erlsrv.exe. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COUCHDB-963) Erlang processes crash when running the delayed_commits test on Windows Server 2008
[ https://issues.apache.org/jira/browse/COUCHDB-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber updated COUCHDB-963: - Attachment: dch_couch.log couch log from DaveCottlehuber Erlang processes crash when running the delayed_commits test on Windows Server 2008 --- Key: COUCHDB-963 URL: https://issues.apache.org/jira/browse/COUCHDB-963 Project: CouchDB Issue Type: Bug Components: Infrastructure Affects Versions: 1.0.1 Environment: This Windows box is a virtual machine Windows Server 2008 Standard without Hyper-V Service Pack 2 64-bit 2 GB RAM 2 Core Intel Xeon CPU @ 2.53GHz each Reporter: Terry Smith Attachments: Apache CouchDB.debug.2, couch.log, dch_couch.log The debugging I've done points to this being an erlsrv.exe bug. Here my steps to recreate. Install 1.0.1 CouchDB as a service using the Windows Binary Installer. I did not select to Start service after installation. Edit the local.ini to set the logging level to debug. Go to the service control panel and start the Apache CouchDB service. Go to Test Suite in Futon and run the delayed_commits test. After about 15 - 20 seconds go to the service control panel and refresh to see that the service is no longer running. ProcessExplorer verifies the erlsrv.exe and erl.exe processes are not running. The last message in the log is a _restart command that returns 200. When I run CouchDB using CouchDB.bat. The test completes without crashing. When I set the DebugType in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Ericsson\Erlang\ErlSrv\1.1\Apache CouchDB to 1 (DEBUG_TYPE_NEW) to get a erlsrv.exe log, the test completes without crashing. I will attach the log files from CouchDB and erlsrv.exe. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
roadmap
Hi all, With the announce of another /couchdb fork/project embedding couchdb/ I think it's the perfect time to define ourself for next releases. What will be CouchDB 1.2 or 2.0, what do we target, what is our timeline. What is the CouchDB core that will be used by other projects basically. Having a defined timeline, ie defined deadlines for freeze, release, ... is important in this context. It means that releases don't depend on external factors: we, the Apache CouchDB project follows its own agenda. There are other reasons for that of course. So can we try to define this time a good old roadmap? What will be the next couchdb? For me: - Plugin support - improved CouchApp engine - Improve possibilities to integrate CouchDB in other projects - Clean API, so couchdb features can be called more easily in other erlang programs or plugins Other feature I wish: - Official Apache CouchDB clustering layer plug - Official Search Plugin based on Apache Lucene that can be used like riak search or cloudant search ... and you ? - benoît
[jira] Commented: (COUCHDB-963) Erlang processes crash when running the delayed_commits test on Windows Server 2008
[ https://issues.apache.org/jira/browse/COUCHDB-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991852#comment-12991852 ] Dave Cottlehuber commented on COUCHDB-963: -- Last note for the night - there *is* a difference between the service the .bat file. batch uses werl.exe service uses erlsrv.exe erl.exe. There's 2 commits that might help resolve this: Jan's parameters in couchdb.bat are not (yet) included in the service config: https://github.com/apache/couchdb/commit/bbd0703f769bac618c0dec22ebf2d14b0a5df5b8 needs to be included into https://github.com/apache/couchdb/blob/trunk/etc/windows/couchdb.iss.tpl#L77 Damien's older use werl.exe not erl.exe: https://github.com/apache/couchdb/blob/trunk/bin/couchdb.bat.tpl.in#L23 Some things to try; - running init:restart() from the erl or werl console directly -changing the service parameters to match Jan's commit - use psexec -s (from sysinternals.com) to launch an interactive prompt under system acct, and try couchdb.bat from there? using the config from the service instead of the batch file - does it fail under normal user acct as well? Cheers Dave Erlang processes crash when running the delayed_commits test on Windows Server 2008 --- Key: COUCHDB-963 URL: https://issues.apache.org/jira/browse/COUCHDB-963 Project: CouchDB Issue Type: Bug Components: Infrastructure Affects Versions: 1.0.1 Environment: This Windows box is a virtual machine Windows Server 2008 Standard without Hyper-V Service Pack 2 64-bit 2 GB RAM 2 Core Intel Xeon CPU @ 2.53GHz each Reporter: Terry Smith Attachments: Apache CouchDB.debug.2, couch.log, dch_couch.log The debugging I've done points to this being an erlsrv.exe bug. Here my steps to recreate. Install 1.0.1 CouchDB as a service using the Windows Binary Installer. I did not select to Start service after installation. Edit the local.ini to set the logging level to debug. Go to the service control panel and start the Apache CouchDB service. Go to Test Suite in Futon and run the delayed_commits test. After about 15 - 20 seconds go to the service control panel and refresh to see that the service is no longer running. ProcessExplorer verifies the erlsrv.exe and erl.exe processes are not running. The last message in the log is a _restart command that returns 200. When I run CouchDB using CouchDB.bat. The test completes without crashing. When I set the DebugType in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Ericsson\Erlang\ErlSrv\1.1\Apache CouchDB to 1 (DEBUG_TYPE_NEW) to get a erlsrv.exe log, the test completes without crashing. I will attach the log files from CouchDB and erlsrv.exe. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: roadmap
On Tue, Feb 8, 2011 at 10:24, Benoit Chesneau bchesn...@gmail.com wrote: ... and you ? Most of all, I want a better schedule/insight into the release process. Even when reading the dev list, it's completely unclear when I might expect the next release or what the blockers are. Releases seem to just keep slipping, or maybe releasing isn't a very big priority, at least that's what it looks like from the outside. For the rest, I would like more documentation. The CouchOne API documentation is a step in the right direction, having good docs about the query server protocol would also be very helpful. Yes, I realize I can read the couchjs JS code, but that's not a substitute for good docs. The new Futon that Mikeal was working on would be nice to have. As for more pie-in-the-sky things, it would be nice to have more efficient view indexing (using multiple processes, for example -- map/reduce should enable that, right?) and an official way to do full-text search. Cheers, Dirkjan
Re: roadmap
On Tue, Feb 8, 2011 at 11:24 AM, Benoit Chesneau bchesn...@gmail.comwrote: ... and you ? - erlang api / plugin support - easier build process on Windows -juhani
[jira] Commented: (COUCHDB-926) Compaction does not release file descriptors
[ https://issues.apache.org/jira/browse/COUCHDB-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991951#comment-12991951 ] Bob Clary commented on COUCHDB-926: --- While the situation in 1.0.2 is much improved over 1.0.1, there are still cases where the deleted files are not released and are still held open by beam. I don't have specific steps to reproduce however it appears to be related to heavy load with couchdb crashing after compacting views and leaving the original file open. Compaction does not release file descriptors Key: COUCHDB-926 URL: https://issues.apache.org/jira/browse/COUCHDB-926 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.0.1 Environment: Ubuntu 9.04/10.4 Reporter: Russell van der Walt Assignee: Filipe Manana Fix For: 1.0.2, 1.1 Attachments: test_comp.sh When couch compacts a database, file descriptors of the deleted files are left open, causing the freed disk space to not be released to the system. With regular compaction, the system eventually runs out of disk space. There is a conversation thread in the user mailing list titled Couch not releasing deleted files that gives more insight into the problem, but I have been unable to find a bug report for it, so please accept my apologies if this has already been dealt with. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: roadmap
+1 full-text search +1 documentation On Tue, Feb 8, 2011 at 4:07 AM, Juhani Ränkimies juh...@juranki.com wrote: On Tue, Feb 8, 2011 at 11:24 AM, Benoit Chesneau bchesn...@gmail.comwrote: ... and you ? - erlang api / plugin support - easier build process on Windows -juhani
Re: roadmap
On Tue, Feb 8, 2011 at 10:33 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Tue, Feb 8, 2011 at 10:24, Benoit Chesneau bchesn...@gmail.com wrote: ... and you ? Most of all, I want a better schedule/insight into the release process. Even when reading the dev list, it's completely unclear when I might expect the next release or what the blockers are. Releases seem to just keep slipping, or maybe releasing isn't a very big priority, at least that's what it looks like from the outside. For the rest, I would like more documentation. The CouchOne API documentation is a step in the right direction, having good docs about the query server protocol would also be very helpful. Yes, I realize I can read the couchjs JS code, but that's not a substitute for good docs. The new Futon that Mikeal was working on would be nice to have. As for more pie-in-the-sky things, it would be nice to have more efficient view indexing (using multiple processes, for example -- map/reduce should enable that, right?) and an official way to do full-text search. Cheers, Dirkjan +1 to the above
Re: roadmap
On Tue, Feb 8, 2011 at 16:57, Noah Slater nsla...@apache.org wrote: For step 2, we follow the roadmap that is generated in JIRA. That is, the roadmap is constantly maintained through ticket work and ticket maintenance. A link to this is even included prominently on the project homepage. We have found that maintaining a HTML roadmap separately to JIRA is too much trouble. Or, at least, we could infer that from the fact it was never updated by anyone. The roadmap (as a JIRA view) is effectively discussed on this list, and then codified through the tickets. I think that's Good Enough. And if it's not, then maybe we need to be smarter about how we use JIRA. Okay, the roadmap is somewhat useful, and I wasn't aware of it. Still, the problem I have is that it seems like there is a tendency to make releases large; it seems like there's little control against devs wanting to add their one more thing. Particularly for bugfix releases; from 1.0.1 it took almost 6 months for 1.0.2 to get released. In between, there were a little under 100 revisions on the 1.0.x branch, presumably most of those fixing bugs users could actually run into. It seems valuable to me if the community could have gotten some of these fixes sooner. I do realize the Apache release process is rather heavyweight, and that CouchDB only recently got a second RM, but it would still be nice if it was possible to have more timely releases. (And I also agree with till's sentiment about roadmaps.) Cheers, Dirkjan
Re: roadmap
We do need to improve at releases, though I think we can all agree that 1.0.2 was just a particularly difficult one, pretty atypical. As for roadmap, I can see a need to revisit it. I'm not sure what should be on it, I suspect everyone has their pet feature or ten to add. So, I'm wary about fragmenting/diluting what we have by trying to put too much inside couchdb itself. Instead, I think Benoit is on to something by talking about pluggability. At the very least, couchdb can make it easy to embed and extend it in ways that are minimally likely to be broken by us in future releases. It's not clear to me that couchdb would benefit by bundling clustering and search. Lucene has an approach that might work for us, namely where there's an explicit core project, with a number of supplementary parts. Releases are aligned for all of them, but the separation is pretty clear. B. On Tue, Feb 8, 2011 at 4:14 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Tue, Feb 8, 2011 at 16:57, Noah Slater nsla...@apache.org wrote: For step 2, we follow the roadmap that is generated in JIRA. That is, the roadmap is constantly maintained through ticket work and ticket maintenance. A link to this is even included prominently on the project homepage. We have found that maintaining a HTML roadmap separately to JIRA is too much trouble. Or, at least, we could infer that from the fact it was never updated by anyone. The roadmap (as a JIRA view) is effectively discussed on this list, and then codified through the tickets. I think that's Good Enough. And if it's not, then maybe we need to be smarter about how we use JIRA. Okay, the roadmap is somewhat useful, and I wasn't aware of it. Still, the problem I have is that it seems like there is a tendency to make releases large; it seems like there's little control against devs wanting to add their one more thing. Particularly for bugfix releases; from 1.0.1 it took almost 6 months for 1.0.2 to get released. In between, there were a little under 100 revisions on the 1.0.x branch, presumably most of those fixing bugs users could actually run into. It seems valuable to me if the community could have gotten some of these fixes sooner. I do realize the Apache release process is rather heavyweight, and that CouchDB only recently got a second RM, but it would still be nice if it was possible to have more timely releases. (And I also agree with till's sentiment about roadmaps.) Cheers, Dirkjan
Re: roadmap
On 8 Feb 2011, at 16:08, till wrote: IMHO a roadmap is defined by more than there's a new jira issue, we need to fix it with the next release. I think you're misunderstanding me. In JIRA, you can pin tickets to release versions. This is a perfectly good way of constructing a roadmap. And if the thing you want isn't in JIRA as a ticket to pin to a release version, that's a good opportunity for you to create one.
Re: roadmap
On 8 Feb 2011, at 16:14, Dirkjan Ochtman wrote: Still, the problem I have is that it seems like there is a tendency to make releases large; it seems like there's little control against devs wanting to add their one more thing. Particularly for bugfix releases; from 1.0.1 it took almost 6 months for 1.0.2 to get released. In between, there were a little under 100 revisions on the 1.0.x branch, presumably most of those fixing bugs users could actually run into. It seems valuable to me if the community could have gotten some of these fixes sooner. I need someone else to weigh in on this, but I believe the reason was because of a few critical bugs that were being worked on. And not, as you suggest, because we were suffering from a Just One More Thing problem. I'd really need Jan or Chris to comment though as I use them as a conduit for judging this stuff.
Re: roadmap
You're absolutely right. 1.0.2 was ready to go quite some time ago but several bugs were found as we were releasing. We decided, as a team, that we couldn't ship with the bugs that were found, so we elected to fix them and delay the release. I think that was the right decision. We should only release when we feel the software is ready, not when some ultimately arbitrary day looms. B. On Tue, Feb 8, 2011 at 4:32 PM, Noah Slater nsla...@apache.org wrote: On 8 Feb 2011, at 16:14, Dirkjan Ochtman wrote: Still, the problem I have is that it seems like there is a tendency to make releases large; it seems like there's little control against devs wanting to add their one more thing. Particularly for bugfix releases; from 1.0.1 it took almost 6 months for 1.0.2 to get released. In between, there were a little under 100 revisions on the 1.0.x branch, presumably most of those fixing bugs users could actually run into. It seems valuable to me if the community could have gotten some of these fixes sooner. I need someone else to weigh in on this, but I believe the reason was because of a few critical bugs that were being worked on. And not, as you suggest, because we were suffering from a Just One More Thing problem. I'd really need Jan or Chris to comment though as I use them as a conduit for judging this stuff.
Re: Sandboxed Futon development
Hello, you can directly work on ${COUCHDB}\share\couchdb\www to develop your features, the couchdb http server will reflect your changes, but the merging will of course be complicated. Perhaps you can ask Mikeal that started to recode futon from scratch using sammy.js ( https://github.com/mikeal/couchdb/tree/sammy ). The other way is to make it as a couchapp : the only thing you'll have to change is the path to the server root ( that is ../ when you hit http://server.com:5984/_utils; but is ../../ when using http://server.com:5984/_design/futon/index.html; ) Regards, Mickael - Mail Original - De: Mihai Alexandru Bîrsan alexandru.m.bir...@gmail.com À: dev@couchdb.apache.org Envoyé: Vendredi 4 Février 2011 15h45:04 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Sandboxed Futon development Hi! I'm a skilled JavaScript developer and I'm interested in developing features for Futon. I'd like to know if it's possible to work on Futon without having to build CouchDB. The ideal environment would be to edit the files under ${COUCHDB}\share\couchdb\www and have that managed with either SVN or GIT. Here are my questions: • Where could I find guidelines for developing Futon? (If any.) • What should I do to have pull requests considered? Ideally I'd like to publish my work, should it prove useful to a greater number of people. • Where can I find an issue tracker for Futon? I have a list of features that I'd like to implement for personal use (including a better JavaScript editor for map/reduce functions, a deep-level JSON editor and keyboard shortcuts); after I'm done with the features I'm interested in, I might take in other issues and bugs to work on. Thanks, Mihai Alexandru Bîrsan http://twitter.com/mihaibirsan http://ro.linkedin.com/in/mihaibirsan
Re: CouchOne + Membase = Couchbase
On Feb 7, 2011, at 11:41 PM, Dirkjan Ochtman wrote: Congratulations to all of you! On Tue, Feb 8, 2011 at 07:41, Jan Lehnardt j...@apache.org wrote: Instead of dwelling on the merger or technology, I'd like to address likely questions about the relationship between Couchbase and Apache CouchDB. It is simple, really: at CouchOne we were 100% committed on the Open Source side of things and at Couchbase we will continue to do so at the same degree. In terms of organisation, Couchbase will be it's own independent Open Source project that has Apache CouchDB and memcached as dependencies, but adds a few things of its own that warrant being its own project. Our combined engineering team, led by Damien, will continue to contribute to Apache CouchDB in the same way as we've been to date, only more. I can't wait to share with you what we'll come up with :) And thanks for this summary of the technical side of things. Could we get a more technical, technical summary here on the list? I appreciate the emphasis you guys are putting on marketing CouchDB to app developers and stakeholders, but as someone who's already sold on it, I'm still confused by what Couchbase means for the future of CouchDB. A few months ago, I read about BigCouch: BigCouch = (CouchDB + Amazon Dynamo clustering theory) That sounds neat, and I was getting the impression this was done in Erlang in such a way it could become part of core and was excited for it. Now I'm trying to figure out what Couchbase is, and my reading indicates: Couchbase = (Memcached + magic) + (CouchDB + ponies) Will these new dependencies make CouchDB harder to compile and use for personal deployments? How does merging in an in-memory cache provide the clustered resiliency I was hoping would be possible by using BigCouch? I'd never heard of Membase before last night, so I guess I'm just feeling a bit like a nervous IT guy hearing the platform he relies on is about to change in ways he doesn't understand. I'd feel more comfortable if I knew what the magic and ponies really were at a code base level, so I could understand better how they will change things for me and my little Couch apps. I can tell the CouchOne guys are excited about this, though, and trust it means good things for the CouchDB community. Congrats, and best wishes! -natevw
Re: roadmap
I would like a more formal direction on the future of couchapps. I am unsure how couchapps will proceed, but one thing i would like to see is the ability of your basic internet users to be able to form their own couchapps by easily integrating other couchapps into their databases, modifying to their content (most 'simple' users are content with just basic color and image changes). For example, a user may 'see' something cool on someones elses site/couch and would like to copy it to theirs. This 'copying' should be as easy as humanly possible. Any complications will only hinder the adoption of couchapps to the public in my opinion. Ideally this 'copying' should be done with a simple push of a button. This leads me to another need couchapps (and they're couchAPERS) must discuss - Standardization. I imagine it will be 'hard' if we don't begin to standardize some of the aspects of couchapps. For example - blog posts. There should be a standard way of 'inputting' blog posts into ones of couch, such that others may easily 'replicate' or 'pull from' peoples blogs and have them appear on their couches. Of course this 'standardization' should also not limit ones ability to change the code. Same thing goes for messaging. It would be nice if we would start forming a standardized 'messaging' system such that messages posted on users A blog will (to steal from Jan) automagically appear on users B blog. (think I.R.C. amongst couches). In short, i believe the future of couchapps depends upon getting your mother to be able to make her own (and feel like she made her own). -Pete
Re: CouchOne + Membase = Couchbase
Nathan, I'll clarify what I can for the bits I know about. One important part of Bigcouch is to be API compatible with couchdb. Obviously there are some places where this must break down (say, controlling sharding and r/w/n consistency) but to a large degree, we succeed at that. It's also straightforward to test it out locally ('make dev', just like couchdb ). I can't speak for Couchbase, will have to see when it comes out. So, to your technical points, as best I can tell, you shouldn't expect to have a harder time using or testing these products, they should work well together. Finally, I cannot reveal how many magic ponies we use in the creation of Bigcouch, but I can assure you that they are all ethically treated. B. On Tue, Feb 8, 2011 at 5:35 PM, Nathan Vander Wilt nate-li...@calftrail.com wrote: On Feb 7, 2011, at 11:41 PM, Dirkjan Ochtman wrote: Congratulations to all of you! On Tue, Feb 8, 2011 at 07:41, Jan Lehnardt j...@apache.org wrote: Instead of dwelling on the merger or technology, I'd like to address likely questions about the relationship between Couchbase and Apache CouchDB. It is simple, really: at CouchOne we were 100% committed on the Open Source side of things and at Couchbase we will continue to do so at the same degree. In terms of organisation, Couchbase will be it's own independent Open Source project that has Apache CouchDB and memcached as dependencies, but adds a few things of its own that warrant being its own project. Our combined engineering team, led by Damien, will continue to contribute to Apache CouchDB in the same way as we've been to date, only more. I can't wait to share with you what we'll come up with :) And thanks for this summary of the technical side of things. Could we get a more technical, technical summary here on the list? I appreciate the emphasis you guys are putting on marketing CouchDB to app developers and stakeholders, but as someone who's already sold on it, I'm still confused by what Couchbase means for the future of CouchDB. A few months ago, I read about BigCouch: BigCouch = (CouchDB + Amazon Dynamo clustering theory) That sounds neat, and I was getting the impression this was done in Erlang in such a way it could become part of core and was excited for it. Now I'm trying to figure out what Couchbase is, and my reading indicates: Couchbase = (Memcached + magic) + (CouchDB + ponies) Will these new dependencies make CouchDB harder to compile and use for personal deployments? How does merging in an in-memory cache provide the clustered resiliency I was hoping would be possible by using BigCouch? I'd never heard of Membase before last night, so I guess I'm just feeling a bit like a nervous IT guy hearing the platform he relies on is about to change in ways he doesn't understand. I'd feel more comfortable if I knew what the magic and ponies really were at a code base level, so I could understand better how they will change things for me and my little Couch apps. I can tell the CouchOne guys are excited about this, though, and trust it means good things for the CouchDB community. Congrats, and best wishes! -natevw
Re: roadmap
I'm going to chime in here and say that improved build support for Android would be terrific. There are already some patches available for this and it would be nice to see them included in the official releases. Hopefully this doesn't equate with asking for ponies. I'd be happy to assist with testing or anything else that would help in this regard. Cheers, Matt -- Matt Adams Radical Dynamic www.radicaldynamic.com
Re: CouchOne + Membase = Couchbase
On 8 Feb 2011, at 19:26, Paul Davis wrote: A few months ago, I read about BigCouch: BigCouch = (CouchDB + Amazon Dynamo clustering theory) That sounds neat, and I was getting the impression this was done in Erlang in such a way it could become part of core and was excited for it. It is and there's still a general agreement that it will be. The issues holding it back are mostly technical in that we need to refactor our source tree which is being held up by things like waiting for the new replicator to land. Now I'm trying to figure out what Couchbase is, and my reading indicates: Couchbase = (Memcached + magic) + (CouchDB + ponies) Will these new dependencies make CouchDB harder to compile and use for personal deployments? How does merging in an in-memory cache provide the clustered resiliency I was hoping would be possible by using BigCouch? I'd never heard of Membase before last night, so I guess I'm just feeling a bit like a nervous IT guy hearing the platform he relies on is about to change in ways he doesn't understand. Couchbase is not Apache CouchDB. There are no new dependencies that are suddenly going to be required by CouchDB. I'd feel more comfortable if I knew what the magic and ponies really were at a code base level, so I could understand better how they will change things for me and my little Couch apps. I can tell the CouchOne guys are excited about this, though, and trust it means good things for the CouchDB community. For the foreseeable future, absolutely nothing is going to change for you. Its always possible that we'll start to see some patches coming back from Couchbase employees into Apache CouchDB, but as with all other development they'll go through the same development processes we've been using since CouchDB came to Apache. Spot on, all of it, thanks Paul :) Cheers Jan --
Re: CouchOne + Membase = Couchbase
Ah, ok. I think it was mostly this in the press FAQ that confused me: How will your technologies and products be integrated? We plan to roll out the blended product line in several stages over the next few months. What I'm hearing is this Couchbase blended product is more or less a line of infrastructure services that Couchbase the company is weaving together with Apache CouchDB as one component and Membase as another and the new company's combined wizardry as another. Synergy As A Service or something, not an actual merging of *projects* into an inseparable tarball. I apologize for not reading Jan's original email on this thread more thoroughly; I had assumed it was basically the same press release stuff, but it actually makes this abundantly clear: Couchbase will be it's own independent Open Source project that has Apache CouchDB and memcached as dependencies, but adds a few things of its own that warrant being its own project. That *is* super exciting! These kind of higher-level projects and business models both demonstrate and promote CouchDB's maturity as The Future of the web. (I was going to say maturity as a platform but let's just be honest here :-) thanks, -natevw On Feb 8, 2011, at 10:26 AM, Paul Davis wrote: A few months ago, I read about BigCouch: BigCouch = (CouchDB + Amazon Dynamo clustering theory) That sounds neat, and I was getting the impression this was done in Erlang in such a way it could become part of core and was excited for it. It is and there's still a general agreement that it will be. The issues holding it back are mostly technical in that we need to refactor our source tree which is being held up by things like waiting for the new replicator to land. Now I'm trying to figure out what Couchbase is, and my reading indicates: Couchbase = (Memcached + magic) + (CouchDB + ponies) Will these new dependencies make CouchDB harder to compile and use for personal deployments? How does merging in an in-memory cache provide the clustered resiliency I was hoping would be possible by using BigCouch? I'd never heard of Membase before last night, so I guess I'm just feeling a bit like a nervous IT guy hearing the platform he relies on is about to change in ways he doesn't understand. Couchbase is not Apache CouchDB. There are no new dependencies that are suddenly going to be required by CouchDB. I'd feel more comfortable if I knew what the magic and ponies really were at a code base level, so I could understand better how they will change things for me and my little Couch apps. I can tell the CouchOne guys are excited about this, though, and trust it means good things for the CouchDB community. For the foreseeable future, absolutely nothing is going to change for you. Its always possible that we'll start to see some patches coming back from Couchbase employees into Apache CouchDB, but as with all other development they'll go through the same development processes we've been using since CouchDB came to Apache.
Re: roadmap
On Tue, Feb 8, 2011 at 01:24, Benoit Chesneau bchesn...@gmail.com wrote: Hi all, With the announce of another /couchdb fork/project embedding couchdb/ I think it's the perfect time to define ourself for next releases. What will be CouchDB 1.2 or 2.0, what do we target, what is our timeline. What is the CouchDB core that will be used by other projects basically. Having a defined timeline, ie defined deadlines for freeze, release, ... is important in this context. It means that releases don't depend on external factors: we, the Apache CouchDB project follows its own agenda. There are other reasons for that of course. So can we try to define this time a good old roadmap? What will be the next couchdb? For me: - Plugin support - improved CouchApp engine - Improve possibilities to integrate CouchDB in other projects - Clean API, so couchdb features can be called more easily in other erlang programs or plugins Other feature I wish: - Official Apache CouchDB clustering layer plug - Official Search Plugin based on Apache Lucene that can be used like riak search or cloudant search ... and you ? - benoît I agree mostly with Benoit. My priorities are: - a really good embedding story (android, desktop apps, couchbase, etc ...) - a really good plugin story (geocouch, lucene search, easy to compile against couchdb sources) - a really good build story (particularly android, windows) - clean internal APIs -Randall
Re: roadmap
On 8 Feb 2011, at 17:32, Noah Slater wrote: On 8 Feb 2011, at 16:14, Dirkjan Ochtman wrote: Still, the problem I have is that it seems like there is a tendency to make releases large; it seems like there's little control against devs wanting to add their one more thing. Particularly for bugfix releases; from 1.0.1 it took almost 6 months for 1.0.2 to get released. In between, there were a little under 100 revisions on the 1.0.x branch, presumably most of those fixing bugs users could actually run into. It seems valuable to me if the community could have gotten some of these fixes sooner. I need someone else to weigh in on this, but I believe the reason was because of a few critical bugs that were being worked on. And not, as you suggest, because we were suffering from a Just One More Thing problem. I'd really need Jan or Chris to comment though as I use them as a conduit for judging this stuff. Robert already confirmed this, but I'd like to point out that Noah's analysis is apt. -- As for the suggestions for more transparency regarding what new features are being worked on and when do they land in which version I agree that we can do better and I'll take on doing some of the legwork here. I also like the proposed features, but I don't think committing to ship pony-features without seeing any code is a good idea — just to paint an extreme, so far nobody suggested that. Cheers Jan --
Re: roadmap
On Tue, Feb 8, 2011 at 9:40 PM, Jan Lehnardt j...@apache.org wrote: On 8 Feb 2011, at 17:32, Noah Slater wrote: On 8 Feb 2011, at 16:14, Dirkjan Ochtman wrote: Still, the problem I have is that it seems like there is a tendency to make releases large; it seems like there's little control against devs wanting to add their one more thing. Particularly for bugfix releases; from 1.0.1 it took almost 6 months for 1.0.2 to get released. In between, there were a little under 100 revisions on the 1.0.x branch, presumably most of those fixing bugs users could actually run into. It seems valuable to me if the community could have gotten some of these fixes sooner. I need someone else to weigh in on this, but I believe the reason was because of a few critical bugs that were being worked on. And not, as you suggest, because we were suffering from a Just One More Thing problem. I'd really need Jan or Chris to comment though as I use them as a conduit for judging this stuff. Robert already confirmed this, but I'd like to point out that Noah's analysis is apt. -- As for the suggestions for more transparency regarding what new features are being worked on and when do they land in which version I agree that we can do better and I'll take on doing some of the legwork here. I also like the proposed features, but I don't think committing to ship pony-features without seeing any code is a good idea — just to paint an extreme, so far nobody suggested that. Cheers Jan -- What is it supposed to mean ? A roadmap is a a detailed plan to guide progress toward a goal . Why couldn't we define goals ? - benoît
Fwd: [IANA #411617] Application for port-number: couchdbs
Help appreciated. He raises a good point though, as those links don't work now. I'm not sure what level of description they require. Probably nothing more than a handful of paragraphs to explain how CouchDB is a special use-case for HTTP. In the original submission for TCP 5984, I pointed out that TCP 80 is specifically reserved for World Wide Web HTTP. My argument hinged on the fact that CouchDB is expected to be run on a machine (perhaps on a private interface) that is simultaneously serving up this kind of World Wide Web traffic, and so this warranted a separate port. Begin forwarded message: Dear Noah Slater: Thank you for your patience while your application was being reviewed. The expert review team still has questions for clarifications with respect to your request. - You provided the following for couchdb (#5984): http://www.couchdbwiki.com/index.php?title=CouchDb_Quick_Overview http://www.couchdbwiki.com/index.php?title=Technical_Overview http://www.couchdbwiki.com/index.php?title=HTTP_REST_API Do you have an updated description of the protocol CouchDB over TLS/SSL? - It will also be useful to include a fundamental description in the template itself rather than points. URLs are useful, but they might not be reachable in the future. IESG requires that the technical description shall be documented in the application for future reference purposes. If we do not receive the information within 30 days (i.e. 2011-03-10), your request will be resolved without prejudice, as a matter of administrative procedure.
Re: roadmap
On 8 Feb 2011, at 20:53, Benoit Chesneau wrote: What is it supposed to mean ? A roadmap is a a detailed plan to guide progress toward a goal . Why couldn't we define goals ? I think Jan's point is that we use the JIRA roadmap as an advisory only, and never state that we are committing to it. That means that if I create a ticket for CouchDB to be able to read and send email, it doesn't hold-up the project. Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. — Jamie Zawinski
[jira] Created: (COUCHDB-1062) 1.0.1 sends malformed reply to some POST and GETs
1.0.1 sends malformed reply to some POST and GETs - Key: COUCHDB-1062 URL: https://issues.apache.org/jira/browse/COUCHDB-1062 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.0.1 Environment: Ubuntu 10.10 Reporter: Ian Hobson Priority: Minor The HTTP reply body should end with CRLF when chunked format is used, according to http://www.jmarshall.com/easy/http/#http1.1c2 Some replies I am getting from couchDB actually end with a single LF when sent in chunked format. This is from some logging software I placed in the network between couchDB and the user code. \r is replaced with CR and \n with LF. sent: PUT /cubic/c182c1a2f71c3547ccee455563008ac6 HTTP/1.1CRLFHost: localhost:5981CRLFContent-Length: 247CRLFContent-Type: application/jsonCRLFAccept: applica tion/jsonCRLFUser-Agent: CouchDB-Python/0.8CRLFCRLF sent: {town: FXXyyzz, name: zxx, country: UK, _rev: 11-d4412c9350af6bf0a16f53ae5d7611a2, street: , postCode: W3 4HU, lega lName: zzyy, _id: c182c1a2f71c3547ccee455563008ac6, type: Company, cubRef: 3212} recv: HTTP/1.1 201 CreatedCRLFServer: CouchDB/1.0.1 (Erlang OTP/R13B)CRLFLocation: http://localhost:5981/cubic/c182c1a2f71c3547ccee455563008ac6CRLFEtag: 12-c 4a6825c8ba99bef469aa7ea3add4600CRLFDate: Tue, 08 Feb 2011 22:37:29 GMTCRLFContent-Type: application/jsonCRLFContent-Length: 96CRLFCache-Control: must-revalid ateCRLFCRLF recv: {ok:true,id:c182c1a2f71c3547ccee455563008ac6,rev:12-c4a6825c8ba99bef469aa7ea3add4600}LF sent: GET /cubic/_design/Company/_view/by_name HTTP/1.1CRLFHost: localhost:5981CRLFContent-Length: 0CRLFAccept: application/jsonCRLFUser-Agent: CouchDB-Python /0.8CRLFCRLF recv: HTTP/1.1 200 OKCRLFTransfer-Encoding: chunkedCRLFServer: CouchDB/1.0.1 (Erlang OTP/R13B)CRLFEtag: 9754IR9J5ESL770XGNGUKJ5K2CRLFDate: Tue, 08 Feb 2011 22:37:30 GMTCRLFContent-Type: application/jsonCRLFCache-Control: must-revalidateCRLFCRLF recv: a0CRLF{total_rows:9,offset:0,rows:[CRLF{id:c182c1a2f71c3547ccee45556300770e,key:[A first Company,231,345 East of Eden,Manchester,nul l],value:null}CRLF77CRLF,CRLF{id:c182c1a2f71c3547ccee455563001254,key:[C-U-B,1,9-11 March Business Centre,March,null],value:null}CRLF75CRLF, CRLF{id:c182c1a2f71c3547ccee455563003139,key:[Fred Bloggs,302,30 Back Lane,Somewhere,null],value:null}CRLF76CRLF,CRLF{id:c182c1a2f71c3547cc ee455563003de8,key:[Fred Smith,431,30 High street,Somewhere,null],value:null}CRLF83CRLF,CRLF{id:7bc7f2014593d108b5b681fe03002ad6,key:[Joe Hobson,1002,31 xx Dr,Northampton, Nhants,null],value:null}CRLF7cCRLF,CRLF{id:c182c1a2f71c3547ccee455563002e87,key:[Kingfisher Group, 323,33 Westmister Rd,Londonx,null],value:null}CRLF7aCRLF,CRLF{id:c182c1a2f71c3547ccee455563005894,key:[New Company,212,34 Back Street,Anot her Toon,null],value:null}CRLF76CRLF,CRLF{id:c182c1a2f71c3547ccee4555630070dc,key:[Silly Samuel,3223,Street Name,New Towen,null],value:null }CRLF6cCRLF,CRLF{id:c182c1a2f71c3547ccee455563008ac6,key:[zxx,3212,,FXXyyzz,null],value:null}CRLF4CRLFCRLF]}CRLF1CRLFLFCRLF0CRLFCR LF sent: PUT /c etc... The above line ending LF should be followed by a CRLF pair. It isn't. A moment later there is the HTTP/1/1 etc from the next reply. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira