On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau <bchesn...@gmail.com> wrote: > On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith <j...@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.
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.
