On 14. November 2013 at 20:45:55, Ryan Mohr ([email protected]) wrote: > > The show/list thread (posted by [email protected]) 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
Good links. Personally, I like the idea of a lean core, comprising k/v b-tree store on disk + replication. And pretty much everything else as plugin/extensions. For me, CouchDB is JSON docs + attachments, with streaming HTTP API for docs, attachments, views/db, changes, security authorisation + replication. I think the rest could be taken out — plugins, incl show/list and authentication. CouchApps are a unique feature but in principle can be added to any db that supports HTTP, arbitrary binary blobs & mime content type. It’s just that with couch’s other features its just so yummy. I still love the fact that the whole iriscouch website is a single couchdb document. That’s awesome. Maybe an appropriate objective for the project post merge completion? A+ Dave
