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 >
