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 bchesneau@gmail.com
 designates 209.85.220.44 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 10:28:12 +0100
Message-ID: 
 <CAJNb-9odiVAUBwrnG1xLqX6j2Y_u8zSWEHFhV5zHhZay4EDVYA@mail.gmail.com>
Subject: Re: Product management means saying no
From: Benoit Chesneau <bchesneau@gmail.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=047d7b33cb7637f11004eb33d18b

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

On Fri, Nov 15, 2013 at 9: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.
>
> Well I am not sure you want a documented oriented database then ;) Imo yo=
u
are thinking to an object database :)


> 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.
>

lists/shows ! couchapps again. If the doc says that it should be fixed ASAP=
.

>
> Maybe an appropriate objective for the project post merge completion?
>
> A+
> Dave
>
>

--047d7b33cb7637f11004eb33d18b--