I preface this with the fact that I'm fairly interested in exploring this. I think Jason's sentiments are right on in that SpiderMonkey has proven to be a bit of a burden for us to depend on especially from the point of view of instructing new users on how to satisfy that dependency.
That said, the biggest hurdles that come to mind: How much better is the node.js package story? A random node I just logged into doesn't have it immediately available. Are there debs/rpms/whatevers available from the node project? I've only semi sorta investigated sandboxing. This I think is going to be the biggest issue. With spidermonkey we were able to be very specific on what enters the JS VM's world. With node we're going to be in the "remove all the things" territory which is always more worrisome. I know there's some code/module/thing in node for this but I'm under the impression that its not fully fleshed out. And the example project I saw that used it spawned a subprocess for every call which is untenable (though that could be something we change obviously). I'm not at all concerned about dropping E4X support but are there any other issues we'll have to deal with? How about the anonymous function issues we have with spidermonkey trunk? Not that !node will save us from dealing with that particular nugget of awesomeness. Node has a history of API breakage though it appears to have been stabilizing in that respect. How much do we have to worry about that these days? When do I get a unicorn? Most of those are serious questions. On Fri, Jan 25, 2013 at 5:18 AM, Jason Smith <[email protected]> wrote: > This whole branch is an experiment. That is the main point. > > 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. > > Maybe we should not embed JavaScript anymore. Maybe we should just depend > on Node.js being installed. Compare these two statements to a new user: > > Option A: "To build CouchDB, you must have the the SpiderMonkey libjs > library installed, version x.y.z" > Option B: "To build CouchDB, you must have the V8 libraries installed, > version x.y.z" > Option C: "To run CouchDB, you must have Python on your system" > > Everybody has Python installed! Yay! > > So now, just substitute "Node.js" for "Python" and it is a similar > situation. IMO in a couple years Node.js will be nearly as ubiquitous. > > > On Fri, Jan 25, 2013 at 11:10 AM, Dirkjan Ochtman <[email protected] > >wrote: > > > On Fri, Jan 25, 2013 at 12:06 PM, Jason Smith <[email protected]> wrote: > > > This is an experiment just to see how things feel. I want to see how it > > > feels to stop saying "CouchDB requires > > > libjs185/xulrunner/spidermonkey/whatever" and start saying "CouchDB > > > requires Node.js." > > > > What do we need Node.js for, over just v8? > > > > Cheers, > > > > Dirkjan > > > > > > -- > Iris Couch >
