Just to be part of the fun and really add to the mess of options there is this:
https://github.com/ariya/phantomjs I think it's somewhere above v8 and below node. Maybe it would be easier to contain then the node beast for sandboxing and provide developers with some fun new toys. Either way we go, imagine running pouchdb inside of couchdb? mind blown. On Fri, Jan 25, 2013 at 12:27 PM, 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 > > >
