The show/list thread (posted by thomas.b...@ptb.de) recently sparked an interesting debate. Like Joan, I too feel that CouchDB tries to handle way more than it should. (Caveat -- I actually take this stance to the extreme believing that the couchapp behavior and utilities like futon/fauxton shouldn't be included in the core installation.)
IMO the show/list behavior is an application concern, not a database concern, and should be handled by the application server or client. If you think of CouchDB as your database and your application server the line quickly gets blurry. I'm curious, where does the dev team draw the line on couchdb's responsibilities? The fact that it's already an api+database+services suggests there won't be any concrete boundaries. All must be by design. Some related articles: http://insideintercom.io/product-strategy-means-saying-no/ http://zurb.com/article/744/steve-jobs-innovation-is-saying-no-to-1-0
