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:24:31 GMT

On Jan 31, 2013, at 16:20 , Robert Newson <> wrote:

> Part of the difficulty in asserting the correctness of the sandbox is
> that important tests like "cannot read file", "cannot write file",
> "cannot open socket" cannot be written against SpiderMonkey (or,
> presumably, V8) as they simply don't provide those features. Node
> does, and that's the principal advantage of it over V8 as I understand
> things, but it is obviously silly to write a test suite on that basis.

Excellent point. What ways of mitigating to we have?

Can we construct a sandbox that only allows calling of functions that
we specify (has Jason done this?).


> B.
> On 31 January 2013 15:17, Jan Lehnardt <> wrote:
>> 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
>> instead).
>> 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
>>      sake of argument) we should make sure it is compatible.
>>    - Can you all help collecting the minimally available Node versions for systems
>>      we intend to support with master?
>> Cheers
>> Jan
>> --

View raw message