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.161.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=eGGD4oimCdUOfJto/snsTv+hktWKiri5vow8oJlCWkMgXv2u5FMDNZuzTX3iYVJ/Em
         WyxTupWLjiT7nBS3I5v9h15/pgPvDokGMwotYivkomApCpzs1Al6tasQWJBMh8rwlTFs
         6R2bzsG0TRJUZjjlQjGRZ6ItXHnSRElubF85A=
MIME-Version: 1.0
In-Reply-To: <AA6F6097-1F21-4C4A-884A-5F7067BB36F1@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>
	<C543EC69-3AE2-48AA-8B81-7C363B75FB2A@apache.org>
 <AANLkTinvCGE+mDVREXXbmUOJ-cHYXcAnCVEtBJym7eat@mail.gmail.com>
	<AA6F6097-1F21-4C4A-884A-5F7067BB36F1@apache.org>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Mon, 2 Aug 2010 16:34:19 -0400
Message-ID: <AANLkTinu5qrA53f82HQ3-vgXGY_VWqQiqxBXMdxSj-TP@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

On Mon, Aug 2, 2010 at 4:23 PM, J Chris Anderson <jchris@apache.org> wrote:
>
> On Aug 2, 2010, at 1:20 PM, Paul Davis wrote:
>
>>> 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? =
(especially one that can react differentially to doc update failures, can f=
arm work out to multiple cores, etc)
>>>
>>> 2) how can we be backwards compatible with existing code and make it so=
 you can respond to an HTML form POST by rendering "whoops, someone else ed=
ited that before you did, please retry", or "hey it looks like you failed t=
he 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.
>
> Right. This would be the 1) side of what I talked about up there, as it'd=
 be useful for CouchDB 2.0.
>
> For that, maybe a sandboxed Node.js implementation of the show and list, =
etc, would be the best solution.
>
> But I think it'd be better to stick to a single runtime, so if we use emo=
nk for views, we should also use it for show and list.
>
> Chris

Erm, I'm thinking more higher level. Whether or not we use something
like emonk, or continue with couchjs, I'm just saying that instead of
compiling all of the *.js files into a single main.js, we split the
two so the front end side can do something entirely different with its
implementation, ie allow for a full async API that can do all sorts of
crazy things in front of CouchDB. Ie, full app server in front of
CouchDB that can do anything it wants because its in front of the
security wall.

Which is intriguing, because you can suddenly extend features without
touching CouchDB. Imagine arbitrary URL handlers and the such at
various endpoints. You could reimplement things like batch=3Dok. Or
perhaps, time stamping documents. Or perhaps, last write wins
semantics. Or perhaps, pages that include multiple lists or shows.

Anyway, more higher level like that.

Paul Davis