couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Sat, 26 Jan 2013 11:52:18 GMT
On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith <jhs@iriscouch.com> 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.

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