incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Iriele <siriele...@gmail.com>
Subject Re: Product management means saying no
Date Fri, 15 Nov 2013 09:03:28 GMT
Interesting read...

One of the reasons I like CouchDB so much is that it kind of transcends the
traditional notion of a database with http web server like capabilities
that allow for some very interesting architectures. Moving that around and
trying to shift it in either direction would make it "like its
competitors"....I think It should remain as is truth be told. There are
some things that need to be enhanced..and perhaps adding plugins could be
cleaner.

@Dave CouchApps aside, I think CouchDB is just as much one as it is the
other. I recently used the OS Deamons functionality with proxying for a
little reverse proxy action and I can't tell how slick it was. When I
showed my coworkers what was going on they the re-occuring theme was .."It
can do that too?"..Why yes...yes it can :-D


On Fri, Nov 15, 2013 at 12:49 AM, Dave Cottlehuber <dch@jsonified.com>wrote:

> On 14. November 2013 at 20:45:55, Ryan Mohr (ryan@kumu.io) wrote:
> >
> > The show/list thread (posted by thomas.bock@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
>
> 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
>
>

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