couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 14:46:51 GMT
On Thu, Jan 31, 2013 at 1:51 PM, Randall Leeds <>wrote:

> On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith <> wrote:
> > On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <
> >
> >>
> >> 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.

 Quite right. This branch answers half that question: what do you get?

So far, this is my list of good things I've seen:

1. Better code.
1a. Cut almost 3,000 lines of code
1b. Exchanged SM build dependency for Node runtime dependency. This right
here--this summarizes the whole exercise.

2. Very encouraging degree of compatibility. Consider, the 1,500 lines of
view server JS code: none of it was ever intended for Node.js. But the test
suite shows, the two are virtually identical.

 3. Apparently this is already easier to use than homebrew. Homebrew pins
SM apparently to support Mongo (unsure if the latter is true).

4. Got a lot of enthusiasm. (A lot of people tested it and emailed to ask
"why isn't it faster?"). This thread got a lot of feedback about new
protocols, and async APIs, and app-building features. Why? I think when you
say Node.js and CouchDB everybody says "Yes!"

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 you want API stability, then you'll like Node.js. The whole principle of
the project is to be "finished" one day.

Node.js is less likely than Python, say, to break a simple, 300-line repl
program. (My point is: not likely.) But yes, you've put your finger on it.
This is a runtime dependency.

 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

The JS code is already engine-agnostic. My couchjs implementation runs all
that code.

I can also test couchjs directly with a couchjs client I wrote: That tool can read log files
and play them against any couchjs-compatible program. I log the
interactions messages during the test suite. And then I play them back to
both C and Node.js couchjs. They are identical.

I did some work on an async API.


I tried this. But the problem is, list functions provide basically a
blocking getRow() function. Once I realized that, I backed it out.

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?

The word "sandbox" is vague. There is no clear definition. (There is a
mundane historical reason for that: the "sandbox" was whatever the C
program did.)

Prediction: as quickly as we identify sandbox features, somebody can build
a Node.js implementation to reasonable satisfaction. But we'll see.

Iris Couch

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message