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
