On Thu, Nov 14, 2013 at 8:44 PM, Ryan Mohr <r...@kumu.io> wrote: > 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.) > > again list/shows != couchapps .
> 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. > A database process for you the data that you query to return the results. lists and shows are a functional way to do i. Making couchdb an hybrid between a functional database and a document oriented dabase > > 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 Innovations is about to say no. But innovations is also to recognise where it is. The innovation is not in a limited M/R and document store using a btree. The innovation is what makes couchdb different from others and useful. - benoit
