couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 15:17:31 GMT

On Jan 31, 2013, at 15:52 , 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.
> Not all developers have nodejs installed. None of my servers have it.

The question is not if you server have it, but whether you could install a
compatible version easily.

I’d love to hear if you or others are not covered by

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

I’d say this is irrelephant to the view engine. The idea here is that a
Node view engine is much more likely to see progress towards that goal
though as it comes with an enthusiastic community that shares the interest
of having an awesome CouchDB Server (via NPM). NPM is effectively a CouchApp

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

Not a bad point, but also out of scope for this discussion, I’d say. Either
way, bot engines have been ported (SM) or designed (V8) to also run on mobile.
That doesn’t mean all is equal, but the basics for this are there.

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

We have seen zero evolution of the view protocol in the past. My hope is
that with a wider target audience (node folks), we’ll finally get
contributions there.

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

I really like the idea of throwing away all that C code (and gain JS code

And I like that Jason did demonstrate that it is feasible.

Two things remain:

 1. Show that sandboxing is sufficient for our needs
    - can we come up with JS code that is supposed to fail and then make sure it does?

 2. Show that the Node view server works on commonly distributed Node versions.
    - if, say Node 0.6 is widely supported on the Latest-1 Ubuntu release (just for the
      sake of argument) we should make sure it is compatible.
    - Can you all help collecting the minimally available Node versions for systems that
      we intend to support with master?


View raw message