It's an interesting release.. I had been tinkering with the beta. Oddly enough (considering the name) to me it seems really more tempting as a replacement for memcached than for couchdb.
Can someone from Couchbase or someone familiar with their plans please confirm the points here:
* Basic data storage operations must use the memcached API.
* However, the HTTP REST API for basic CRUD operations must be updated to use the memcached protocol.
It seems that the couchdb REST API is no longer supported. Was that due to resource constraints in getting 2.0 shipped or is it an intentional design decision to not support this?
It's not so much that you need to use the memcached API. We've built a set of client libraries that give you a consistent API (check out couchbase.com/develop) though parts are done through memcached binary protocol (for speed) and parts are done through a RESTful interface inspired by CouchDB.
It wasn't about resource constraints; it that we felt going after distributed deployments and having the speed to keep up with application demands (mostly driven by CRUD) was important. That's what devs and ops people kept telling us they'd need.
Can someone from Couchbase or someone familiar with their plans please confirm the points here:
http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase...
Specifically these points:
* Basic data storage operations must use the memcached API.
* However, the HTTP REST API for basic CRUD operations must be updated to use the memcached protocol.
It seems that the couchdb REST API is no longer supported. Was that due to resource constraints in getting 2.0 shipped or is it an intentional design decision to not support this?