Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of siriele2x3@gmail.com
 designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <etPan.5285e005.45592757.5464@akai.jsonified.com>
References: 
 <CAOA1H+++QkT3mz21+hZ1KYZpKi6e5hX_os5Y+MSYZbLvDaDurg@mail.gmail.com>
	<etPan.5285e005.45592757.5464@akai.jsonified.com>
Date: Fri, 15 Nov 2013 01:03:28 -0800
Message-ID: 
 <CAPNuaCga-+9p3mcXVrWJgFpWV-cC16hKu1hBie-6weze9bZP=w@mail.gmail.com>
Subject: Re: Product management means saying no
From: Stanley Iriele <siriele2x3@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001a11c305a4c27a3a04eb337823

--001a11c305a4c27a3a04eb337823
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 o=
n
> 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 =97 plugins, incl show/l=
ist
> 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=92s ju=
st
> that with couch=92s other features its just so yummy. I still love the fa=
ct
> that the whole iriscouch website is a single couchdb document. That=92s
> awesome.
>
> Maybe an appropriate objective for the project post merge completion?
>
> A+
> Dave
>
>

--001a11c305a4c27a3a04eb337823--