incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Product management means saying no
Date Fri, 15 Nov 2013 08:49:09 GMT
On 14. November 2013 at 20:45:55, Ryan Mohr ( wrote:
> The show/list thread (posted by 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:

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?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message