3 ms·

Can someone explain what's so important about this release?

evangineer 15y ago
The biggies I've been personally waiting to see land in this release are: * Added OS Process module to manage daemons outside of CouchDB. * Added HTTP Proxy handler for more scalable externals. What these effectively mean is that you can write CouchDB handlers in the language of your choice as long as they speak http. You can get the full details from the author of the above patches here: http://davispj.com/2010/09/26/new-couchdb-externals-api.html http://davispj.com/2010/09/26/new-couchdb-externals-api.html This makes possible things like LivelyCouch, integrating node.js with Couch: http://www.livelycouch.org/ http://www.livelycouch.org/
- js4all 15y ago
  I didn't know about livelycouch. It seems to be a great idea. Thanks for mentioning it.
evangineer 15y ago
A bunch of the other changes are about making CouchDB more suitable as a public-facing web server, hence the SSL support & improved ETag support for example.
rdtsc 15y ago
Here are some: * Added _replicator database to manage replications. It used to be that if a continuous replication was launched but the server was re-started that replication task was lost. Now it will continue where it left off. * Added support for HTTP range requests for attachments. Just looking at the unit-test for this commit, you can apparently specify a range of bytes out of an attachment and fetch only that. var xhr = CouchDB.request("GET", "/test_suite_db/bin_doc/foo.txt", { headers: {"Range": "bytes=10-15"} }); * Added stale=update_after query option that triggers a view update after returning a stale=ok response. Before, if stale=ok was passed to a view then you'd just get back stale view data and (I am guessing) a view update wasn't triggered. Normally a view update is triggerred the frist time the view is accessed after documents have been updated. However that could take a while for the views to regenerate. Now with stale=update, stale data is returned but an view update is _also_ triggerred in the background. * Added configuration option for TCP_NODELAY aka “Nagle”. Should help for situations where you'd want to trade some throughput for latency. Your packets will be sent out sooner, they will be smaller, but there will probably be lots more of them. See here for more : http://en.wikipedia.org/wiki/Nagle%27s_algorithm

The biggies I've been personally waiting to see land in this release are: * Added OS Process module to manage daemons outside of CouchDB. * Added HTTP Proxy handler for more scalable externals. What these effectively mean is that you can write CouchDB handlers in the language of your choice as long as they speak http. You can get the full details from the author of the above patches here: http://davispj.com/2010/09/26/new-couchdb-externals-api.html http://davispj.com/2010/09/26/new-couchdb-externals-api.html This makes possible things like LivelyCouch, integrating node.js with Couch: http://www.livelycouch.org/ http://www.livelycouch.org/

js4all 15y ago
I didn't know about livelycouch. It seems to be a great idea. Thanks for mentioning it.

evangineer 15y ago

A bunch of the other changes are about making CouchDB more suitable as a public-facing web server, hence the SSL support & improved ETag support for example.

rdtsc 15y ago

Here are some: * Added _replicator database to manage replications. It used to be that if a continuous replication was launched but the server was re-started that replication task was lost. Now it will continue where it left off. * Added support for HTTP range requests for attachments. Just looking at the unit-test for this commit, you can apparently specify a range of bytes out of an attachment and fetch only that. var xhr = CouchDB.request("GET", "/test_suite_db/bin_doc/foo.txt", { headers: {"Range": "bytes=10-15"} }); * Added stale=update_after query option that triggers a view update after returning a stale=ok response. Before, if stale=ok was passed to a view then you'd just get back stale view data and (I am guessing) a view update wasn't triggered. Normally a view update is triggerred the frist time the view is accessed after documents have been updated. However that could take a while for the views to regenerate. Now with stale=update, stale data is returned but an view update is _also_ triggerred in the background. * Added configuration option for TCP_NODELAY aka “Nagle”. Should help for situations where you'd want to trade some throughput for latency. Your packets will be sent out sooner, they will be smaller, but there will probably be lots more of them. See here for more : http://en.wikipedia.org/wiki/Nagle%27s_algorithm