Re: CouchOne + Membase = Couchbase

2011-02-08 Thread Mahesh Paolini-Subramanya
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

2011-02-08 Thread Benoit Chesneau
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

2011-02-08 Thread Dave Cottlehuber (JIRA)

[ 
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

2011-02-08 Thread Dave Cottlehuber (JIRA)

 [ 
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

2011-02-08 Thread Benoit Chesneau
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

2011-02-08 Thread Dave Cottlehuber (JIRA)

[ 
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

2011-02-08 Thread Dirkjan Ochtman
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

2011-02-08 Thread Juhani Ränkimies
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

2011-02-08 Thread Bob Clary (JIRA)

[ 
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

2011-02-08 Thread Zachary Zolton
+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

2011-02-08 Thread till
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

2011-02-08 Thread Dirkjan Ochtman
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

2011-02-08 Thread Robert Newson
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

2011-02-08 Thread Noah Slater

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

2011-02-08 Thread Noah Slater

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

2011-02-08 Thread Robert Newson
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

2011-02-08 Thread mickael . bailly
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

2011-02-08 Thread Nathan Vander Wilt
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

2011-02-08 Thread Peter Nolan

 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

2011-02-08 Thread Robert Newson
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

2011-02-08 Thread Matt Adams
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

2011-02-08 Thread Jan Lehnardt

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

2011-02-08 Thread Nathan Vander Wilt
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

2011-02-08 Thread Randall Leeds
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

2011-02-08 Thread Jan Lehnardt

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

2011-02-08 Thread Benoit Chesneau
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

2011-02-08 Thread Noah Slater
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

2011-02-08 Thread Noah Slater

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

2011-02-08 Thread Ian Hobson (JIRA)
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