Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.214.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAN-3CBJgfE1CF4sK_dQWS1sQQNiKyecgSpwViOQZfHSvdOcczw@mail.gmail.com>
References: 
 <CAN-3CBK3Pq3=kTy82T4LR3Fr27k_u-=QFSo2VRwKHnw4fC-eTg@mail.gmail.com>
	<CAKmKYaCUgd+oxyjP4BcOXz94_2OJOB6du_1hF-nS30EtMGaY0A@mail.gmail.com>
	<CAN-3CBLtSwGSQ8JxMGjFSfAtGOWtr1gjJdvdVRYcsDg3a2-ogw@mail.gmail.com>
	<5102B439.10500@lymegreen.co.uk>
	<CAN-3CBK+yWV0oQX7f1Hsj0XpORvrjpJ7dmEhn4bpHLryKDVmAw@mail.gmail.com>
	<CAFUSCh_knsU-yg-bBu0v8Labq11tYJfcTB1VLrGvFNJkE4YpLQ@mail.gmail.com>
	<CAN-3CBLS_iQJB=n7VVHJ288OOu+5JO-6oJwR=760KmwKE9huQQ@mail.gmail.com>
	<CAFUSCh9zoCvJU638s7n72+oAmJMSzmM9+oett-=Hiccx-hwjhw@mail.gmail.com>
	<CAN-3CBKMdDK7uv4-pKJn5ziPU=my23jXA6S0SQNAP+Jw2bHsow@mail.gmail.com>
	<CAJNb-9oVW9AfngCmd7bJjU34pqsouxYtScAhqCB5p0zUXh6obw@mail.gmail.com>
	<CAJ_m3YCDEtQ8HKSZ8q1uCBaP5Gg08pUxv+4-kX_+xQfjPgt3Hw@mail.gmail.com>
	<CAL+Y1nsoN-voZBexDVO3_xNAdy318uyazXsLyezB2U9vbvv-fQ@mail.gmail.com>
	<CAN-3CBLhsi2hG1XXOFgZNXYq+1Nm8Rb7Gsvq=tmTPaLYO_2r4g@mail.gmail.com>
	<CAAL6JQjUY9C9K7RfjVYJm-kGwNXq4vWEPJti2_bho_FPA9ukTg@mail.gmail.com>
	<CAJ_m3YBaM7wCG=EOcZDk7Mx2gw0dhNdsOoM0oCnKf2Tf_czjrw@mail.gmail.com>
	<CAN-3CBJgfE1CF4sK_dQWS1sQQNiKyecgSpwViOQZfHSvdOcczw@mail.gmail.com>
Date: Thu, 31 Jan 2013 05:51:19 -0800
Message-ID: 
 <CAAL6JQizwBioFWo6hfyVdFrBwr5vdGuHjNToHSdCFvb9Sq05iw@mail.gmail.com>
Subject: Re: Branch to switch from SpiderMonkey to Node.js
From: Randall Leeds <randall.leeds@gmail.com>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith <jhs@iriscouch.com> wrote:
> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>
>>
>> That whole process sounds like not a lot of fun.
>>
>
> Right. That is kind of my point. CouchDB is a JavaScript thing, and
> nowadays people have a very well-adopted and well-understood JavaScript
> engine on their computers. Maybe it should just use that.

(Some) developers have node installed (or can install it easily). End
users are a totally different story. They may be able to install it,
but we're talking about adding a runtime dependency unless we bundle
node.

Imagine you have CouchDB installed and then a future node version
breaks compatibility for some API used by the node-couchjs. You now
have to decide whether to upgrade node or try to have multiple node
versions so couchjs can continue to work.

In short I think this is my issue: we're pushing problems down from
maintainers and packagers to users.

If we're just trying to make the building/packaging/maintaining
process easier, I would rather bundle spidermonkey than bundle node
(or bundle v8 and rewrite couchjs against v8).

Thinking about this all a bit more, maybe this is a viable option:
1) Figure out how to refactor the JS code in couchjs to be engine
agnostic. It likely mostly is already, but we may want to make the I/O
a bit more abstracted and certainly give it an async API
2) Make couchjs an optional configure flag, which builds a couchjs
that wraps step (1)
3) Have node-couchjs included, as pure JS code that also wraps (1),
but don't bundle any dependency like node or v8

I think this would be a good solution unless we can demonstrate
confidently that we can sandbox node appropriately for a view server.
It lets your average developer get by without the spidermonkey hassle,
but a maintainer of a downstream package can decide whether they want
a sandboxed view server and don't mind dealing with spidermonkey
packaging or to punt and add a runtime dependency on node. We could
also run the JS test suite from the CLI using node-couchjs. Is there
anyone who isn't served by this path, or whose problems are worsened
by it?