couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Sat, 26 Jan 2013 21:38:59 GMT
On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau <> wrote:
> On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith <> wrote:
>> Russell, thanks for you comments on the ticket.
>> For the record, I fixed some i/o bugs in couchjs and most of the test suite
>> is passing on my branch now. I have nearly achieved phase 1.
>> I think you probably agree, in a situation like this, the only acceptable
>> approach is the whitelist. I think it might be easy to disable i/o in
>> Node.js, because it is easy to control what is in scope for the guest code.
>> Without access to require() or the fs module, how can code perform i/o?
>> Note, since the stakes are high, we must *confirm* this hypothesis, of
>> course.
>> An interesting exception and challenge for the "no I/O" rule is that of
>> course the entire implementation of view servers is via message passing
>> over stdio.
>> I agree with your comments about npm. Three points:
>> 1. Right, it is inappropriate or out of scope to talk about using
>> modules/packages/npm from the view server. Besides huge security issues, it
>> is only marginally useful within the CouchDB 1.x API. So much of the API is
>> stateless and pure-functional programming.
>> 2. One reason I want to try Node.js (rather than V8) is to open the door to
>> users extending CouchDB and/or building applications with full-on arbitrary
>> Node.js code--totally separate from the view server API: maybe a version
>> 2.x discussion.
> Nothing stop us to open the door to the users by using v8. v8 doenst' share
> anything with the system by default. Imo it would be better to start from 0
> instead of hacking nodejs to remove features that exactly define nodejs.
> nodejs this is v8 + a bunch of code to access to IO. I'm afraid that it can
> be really difficult to remove features rather than adding them in a way you
> can quietly handle permissions. So we could have something àla chromeapps
> where you allows explicitely an app to access to some parts of the system
> or not.
>> 3. Besides security, if someone could demonstrate a great performance gain
>> by e.g. embedding V8 in Erlang then that would be a strong argument against
>> Node.js. I am not holding my breath. We could extend the view server
>> protocol to "upgrade" from stdio to SysV or POSIX shared memory and get a
>> similar performance boost. The Erlang side would be a NIF and the Node side
>> would be a native module--so, C code talking to C code.
> We don't need to be so ugly. The system already give use some possibilities
> to have more concurrency. Instead of using STDIO which where everything is
> serialized we could use for example a TCP or UNIX socket. You don't want to
> use shared memory, it can be very problematic.

I agree with Benoit here. The new protocol I've been mulling over
looks more like a standard network service where we connect to the
view server and then each socket that's opened is a persistent context
so that we're not reevaluating javascript for every map or reduce call
which is quite expensive.

View raw message