Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.214.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=VC2CoJVJHAqGdZQKrjNHjOYbAAW4HLw4mKZ7Gmutv+9Ezzz11IOta84S7fLTTqgERf
         No19v5nX06nVxsS/KxEh7oQKVlZAIXUU3aa2CvgwpUjiVz3GBY/6bAW9qHmGw8vvMmA+
         vq8HsqdB2I9yqxDdQH8zcCBYqVIkbwyYLm+64=
MIME-Version: 1.0
In-Reply-To: <C543EC69-3AE2-48AA-8B81-7C363B75FB2A@apache.org>
References: <AANLkTin=PhtkbQX7SJSoDAgcs3EJ+VZ_BBsKb2fukwnr@mail.gmail.com>
	<AANLkTinte65oBBY1iDhjaV2e4QOrHAs60d0ZBqPb+Hst@mail.gmail.com>
	<AANLkTik1E-NzesS3hxO7zdtSdtM2eVscpcSULOud11Jj@mail.gmail.com>
	<AANLkTimfXM9YM1+TLRuF_SgD_LRhw+Z20vC9bmfg7ikv@mail.gmail.com>
	<AANLkTinF3Ypzk5ujTwD5mr=8v7sJcKkXbTjBAJ_GEDMC@mail.gmail.com>
	<AANLkTinbuVM+bK3=KgqcckgoJM9n1MjRfO3eUW0mmNWg@mail.gmail.com>
	<AANLkTinobdPn+k8fWFmS3OxDBQLALfn=x+9GkLaicsvP@mail.gmail.com>
	<AANLkTintbE3qZkK4c3Xz---fU35tnEh22r2Hib+9+MoJ@mail.gmail.com>
	<AANLkTi=kazQfTsYicZbiKTcqovy9d4Fg5=SswTdAW627@mail.gmail.com>
	<AANLkTinVafxTLYjvyEPRgRPgrwG1a2hzOuBRuo-xGOzM@mail.gmail.com>
	<AANLkTikZ0aYZim01gEFaQOeXgZYcxST074sa5yvF6D_q@mail.gmail.com>
	<AANLkTimDRfYfV3ZhOrD69VoWom0tCbr+c93zVwWkQ2yV@mail.gmail.com>
	<AANLkTimwq+0=CZG_YdJpX_=2V9kVQymkOhQBub7wYPet@mail.gmail.com>
	<AANLkTimujNeUyEvBKxvQnchUNf_Tgxmjc5c6Ew62AHQo@mail.gmail.com>
	<AANLkTi=F8MfeKxL3Q4jxJEnDTtJJ433BKd9X3kdrNGiy@mail.gmail.com>
	<AANLkTi=-KgE1rhmzeOevre3oGfs6P06_-L5fu6NUTMFE@mail.gmail.com>
	<C543EC69-3AE2-48AA-8B81-7C363B75FB2A@apache.org>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Mon, 2 Aug 2010 16:20:21 -0400
Message-ID: <AANLkTinvCGE+mDVREXXbmUOJ-cHYXcAnCVEtBJym7eat@mail.gmail.com>
Subject: Re: Proposal for changes in view server/protocol
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> To clear things up.
>
> There are 2 discussions happing in this thread:
>
> 1) what is the ideal API and protocol for a more capable query server? (e=
specially one that can react differentially to doc update failures, can far=
m work out to multiple cores, etc)
>
> 2) how can we be backwards compatible with existing code and make it so y=
ou can respond to an HTML form POST by rendering "whoops, someone else edit=
ed that before you did, please retry", or "hey it looks like you failed the=
 validation function for reason X"

Thanks for giving me a place to respond to the other side of this thread.

Reading through the part of this thread that deals with _list and
_show and _update and seeing how it doesn't really map onto the view
server semantics very well.

When I think of CouchDB in abstract terms, i think of the core Erlang
code as the core of CouchDB. The view server (the map/reduce part) is
behind couchdb. Hidden from the world.

The _list/_show/_update code sits in front of CouchDB and is more of a
friendly layer to interfacing with CouchDB from client apps. What I've
noticed is that most of the issues could be solved if the code
implementing the front side were just implemented separately. Perhaps
with access to an HTTP client that connects to CouchDB. Or something
that is more async in nature as has been suggested.

Either way, I wonder if the best answer isn't to separate out the
responsibility of frontside and backside apps and write two sets of
JavaScript to deal with both.

Paul Davis