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 15:16:39 GMT
On Thu, Jan 31, 2013 at 2:52 PM, Benoit Chesneau <>wrote:

> On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith <> wrote:
> > On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <
> > >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.
> >
> >
> >
> couchdb is not a javascript thing, This is a database in which one and the
> default engine for M/R is using the language javascript.

That is a good point. It raises the question, if CouchDB is not a
JavaScript thing, is it justified to require a JavaScript build dependency?

Not all developers have nodejs installed. None of my servers have it. A,d
> I'm not alone in that case. Imo we don't take the problem at the right
> angle.  Note that I'm fine to have eventually a nodejs view server around
> if it's needed, that not the question.

> Which problems are we trying to solve ?
> - problem with the spidermonkey distribution. There are many versions
> deployed on different OS/distributions. Even some that aren't packaged by
> mozilla

Yes this is the problem. You are right. This is Jan's answer. CouchDB is
already resilient to a few different runtimes.

- having more concurrency for couchapps and view indexation

Love it, but out of scope in this thread.

> Imo one of these problems can be solved by improving the view protocole. I
> think we could work on a new protocole. And while we are here really
> document the current one as a specification in text.

Love it, but of scope in this thread.

> The second, need some discussions. I'm with randall, I think that porting
> couchjs to v8 is not that hard and would really solve the problem.

I have working code. The test suite passes. I would love to see working,
passing v8 code so we could compare and contrast.

But what is your "problem" to solve? If you are talking about speed and
concurrency and stuff, I think that is a 2.x discussion.

None of
> the distributions have the same  of  nodejs also there is still the
> sandboxing to fix. And it seems really weird to remove I/O on nodejs.
> Things that make the difference between nodejs and v8. Having commonjs is
> another thing. One advantage of v8 vs spidermonkey is that we can embed it
> in our code. the license allows. Also building v8 is a way easier compared
> to spidermonkey.

Can someone please specifically describe a "sandbox" feature? CouchJS
passes the test suite. So what does the sandbox do?

The sandbox is very important. So, surely *somebody* put *some* kind of
test in the test suite. I mean, if passing the test suite isn't good
enough, then what are we talking about?

But I definitely agree with you about security. I would never run CouchJS
(the Node version) in production. So far I am making a list of testable
characteristics of the sandbox. I would like to start testing for them to
compare fairly.

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