On Sat, Jan 26, 2013 at 2: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. > > Not only no I/O but also accidentally keeping state between invocations as well. > 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. > > +1 > 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. > > While related I think this is a different discussion. For the view server I think we should be looking at creating our sandboxed/whitelisted execution environment in a node.js process. Once/if we have a hard dependency on node.js then I think users/community will be able to go hog wild on creating a standard for an arbitrary node.js app server thinger in front of CouchDB and then we can get rid of all the various couchapp bits. > 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. > > > On Fri, Jan 25, 2013 at 9:38 PM, Russell Branca <chewbra...@gmail.com > >wrote: > > > Getting a spec together is a good next step, I'll update COUCHDB-1643 > with > > some ideas. > > > > One distinction that would be useful, is what functionality is needed in > > the view engine for just map/reduce, versus user defined functionality in > > filters/validate/update/show/lists. I'm intrigued by the idea of a fast > DSL > > on top of Erlang for views, and then making it easy to have node.js > > applications for the rest of the pieces, and keeping those separate. > > > > > > -Russell > > > > > > On Fri, Jan 25, 2013 at 12:13 PM, Jason Smith <j...@iriscouch.com> wrote: > > > > > Wow, thanks for so much feedback, Russell! > > > > > > Unfortunately, libmozjs185 is also "a make away" I think. > > > > > > The V8 vs. Node discussion is premature until we clearly define the > > > requirements. What exactly is this "sandbox"? What guarantees or > > invariants > > > does it ensure? I have proposed a specific feature list in > COUCHDB-1643. > > > > > > Without a spec, we sound like this: > > > > > > Salviati: I cut three thousand lines of code and kept 100% > compatibility. > > > Simplicio: Yes, but your implementation does not have a "sand box." > > > Salviati: What is a "sand box"? > > > Simplicio: A "sand box" is that which V8 can provide, but which Node.js > > > cannot. > > > Salviati: But you can write Node modules in C which call the V8 API. > > So... > > > Simplicio: Sandbox! > > > Salviati: But-- > > > Simplicio: SANDBOX! > > > > > > > > > > > > On Sat, Jan 26, 2013 at 2:27 AM, Russell Branca <chewbra...@gmail.com > > > >wrote: > > > > > > > Both Node.js and V8 are a make away, so the question is what else > each > > > > brings to the table. > > > > > > > > I'm of the opinion that the big win of Node.js is npm. I would love > to > > > see > > > > CouchDB extensible by npm modules. I've done some experiments along > > those > > > > lines, but the problem comes back to sandboxing. As you pointed out > > > Jason, > > > > CouchDB's javascript security has not been an issue, because the > > > > SpiderMonkey sandbox is solid. Hopefully someone with deeper > knowledge > > of > > > > Node.js than myself will prove me wrong, but I haven't found a way to > > > > securely sandbox it and still allow the use of require for npm > modules. > > > > > > > > Couple of alternative ideas: > > > > > > > > Option F: Distinguish between core "database" level functionality and > > > > "application" level logic. > > > > > > > > - The internal view engine needs to be simple, efficient and secure. > > Have > > > > this use V8 directly or a DSL on top of Erlang. > > > > - Abstract CouchApp level logic from the core view engine. Things > like > > > list > > > > and show functions are perfect for Node.js and npm. I would love to > see > > > > this extended further to make it even easier to create user defined > > > > functionality. There are so many common patterns, like the user > > > > registration thread that popped up yesterday, where the current > > approach > > > is > > > > to build a little external service, that in my opinion would be > better > > > > served by a more capable CouchApp engine. I'm not saying we should > try > > > and > > > > replace all potential application level logic, but at the very least > > add > > > in > > > > a concept of a "worker" functions that can filter on different event > > > types > > > > (new user, new doc, updated doc, failed validation function, etc etc) > > and > > > > execute some user defined function. > > > > > > > > There are admittedly problems with this approach. Where do filters, > > > > validation functions and update handlers go? This would also require > > > > depending on both V8 and Node.js, which I think is not as big of a > > > problem > > > > if the CouchApp engine is structured in a way to be replaceable with > > > other > > > > implementations. > > > > > > > > Option G: Make all user defined functionality execute in an isolated > > > > context using a remote protocol, and basically turn it into a remote > > > > service. This would make it even easier to build custom engines, but > > has > > > > some interesting properties like allowing you to have the engine > > running > > > on > > > > a separate server. Or fun stuff like spinning up a larger EC2 > instance > > > when > > > > you need to rebuild a view, and then rolling back down when the full > > view > > > > build is done. > > > > > > > > Option H: Build something like JInterface for Javascript, creating a > > > stand > > > > alone Javascript node and switching over to message passing for all > the > > > > jobs. This has some interesting properties for bulk and parallel view > > > > builds. > > > > > > > > > > > > I'm glad to see this conversation coming along. Jason, cool stuff, > > thanks > > > > for taking the initiative on this! > > > > > > > > > > > > -Russell > > > > > > > > > > > > On Fri, Jan 25, 2013 at 10:01 AM, Jason Smith <j...@iriscouch.com> > > wrote: > > > > > > > > > Hi, David. Yes, you make very good points. I even think you (and > > > Benoit) > > > > > may be ultimately correct > > > > > > > > > > I dispute that Node.js is V8. Node is not V8. Node.js is a direct > > link > > > to > > > > > God. When I pray to God in the JavaScript language, God moves > > electrons > > > > > around inside my computer. He writes files to my disk, and He sends > > > > packets > > > > > out my Ethernet cable. > > > > > > > > > > A thought experiment: Find some computer power users or sysadmins. > > > Break > > > > > them into two groups, with one task each: > > > > > > > > > > 1. "Install Node.js on your computer, by any means" > > > > > 2. "Install V8 on your computer, by any means" > > > > > > > > > > Which group would self-report more success? Which group would > > register > > > > more > > > > > frustration? > > > > > > > > > > That is the sort of question I hope to answer (or at least supply > > some > > > > > data). With any luck I can falsify my theory and theology. > > > > > > > > > > > > > > > On Fri, Jan 25, 2013 at 11:35 PM, david martin < > > > > > david.mar...@lymegreen.co.uk > > > > > > wrote: > > > > > > > > > > > On 25/01/13 11:18, Jason Smith wrote: > > > > > > > > > > > >> My **tentative** position is that V8 is a waste of time. We > should > > > use > > > > > >> Node.js, not V8. In other words, we should not change couchjs to > > > link > > > > > >> against libv8.so instead of libmozjs.so. Instead, we should > > > **remove** > > > > > the > > > > > >> couchjs binary and build a 100% compatible node version. Again, > > this > > > > is > > > > > my > > > > > >> *suspicion* but I want to explore it more. > > > > > >> > > > > > >> Embedding V8 is, roughly, the same work as embedding > SpiderMonkey. > > > It > > > > > does > > > > > >> not change much. We still depend on an obscure VM with a quirky > > > build > > > > > >> system. > > > > > >> > > > > > > According to Wiki > > > > > > > > > > > > "Node.js is a packaged compilation of Google's V8 JavaScript > > engine, > > > > the > > > > > > libUV platform > > > > > > abstraction layer, and a core library, which is itself primarily > > > > written > > > > > > in JavaScript." > > > > > > > > > > > > "We still depend on an obscure VM ( so V8 is an obscure VM > although > > > it > > > > is > > > > > > embedded in Node.js ) with a quirky build system." > > > > > > > > > > > > Get rid of all quirky build systems, use rebar which builds > > > everything > > > > > AND > > > > > > produces an installable relocatable executable package containing > > > > Erlang > > > > > VM > > > > > > and V8 VM and C routines as NIF's where required for speed. > > > > > > > > > > > > So Node "is" V8 plus a lot more which is not required > > > > > > > > > > > > > > > > > > -- > > > > > > David Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Iris Couch > > > > > > > > > > > > > > > > > > > > > -- > > > Iris Couch > > > > > > > > > -- > Iris Couch >
