couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 14:52:07 GMT
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.

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
- having more concurrency for couchapps and view indexation

I would add a third one:  beeing able to distribute couchdb with a view
engine that work on mobile platform or that eases the distribution on the
mobile. But this isn't the main problem and not the one we are all trying
to solve if I understood well.

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.

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. 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.

If we are all agree on these two problem let's try to do some action on
them and first we shoudl collect all the current feature we have and that
we don't want to lost, then start to find solution to handle them and fix
the issues we have.


> Iris Couch

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