On Sat, Jan 26, 2013 at 2:31 AM, Jason Smith <[email protected]> wrote: > > Paul, we are in broad agreement, so therefore you are correct by > definition. :) >
+1 > JavaScript has seen a huge explosion of tools to parse, process, rewrite, > etc. JavaScript source code. Esprima is the state of the art (at least in > my peer group) and I have had success with Uglify. > > The builtin view server might become much more sophisticated about how it > handles users' code. (This is actually independent of the Node.js and V8 > discussion.) > > So it is possible the "minor modifications" developers must make could be > automated and done transparently on the CouchDB side, perhaps during a > transitional phase. > > But long-term, we all agree to move away from "naked functions" since they > are not valid JavaScript. > Whole hearted +1 to moving away. I just want to try and avoid the "rewrite all your code" step if possible. While I'm not super enthused about the source code analysis path, I could see using it during a transitionary stage with the intent of just helping users manage the upgrade. > > > On Fri, Jan 25, 2013 at 9:36 PM, Paul Davis > <[email protected]>wrote: > > > On Fri, Jan 25, 2013 at 8:51 AM, Jason Smith <[email protected]> wrote: > > > > > I agree with Benoit, *however* those are out-of-scope for my branch. The > > > experiment is to explore *build* dependencies, nothing else. The Node.js > > > component is simply 100% compatible with couchjs, providing the same API > > > for all the code in share/server/*.js. > > > > > > I am intrigued about hybrid Node/Couchapps, or new ways to do views and > > > build apps, but that's not related to this branch. This branch is to > > > improve building, not running. > > > > > > > > Definitely agree here. We should focus on the view engine and leave the > > other bits until a later time. Definitely agree that we should look into > > feasibility before we rush from one tar pit to another (if that's how it > > turns out). > > > > > > > Paul, > > > > > > Even today people have more success installing Node.js version 0.8 than > > > libmozjs version anything. Node.js ships binaries for every platform. The > > > situation will only improve. Node.js is a rocket ship. > > > > > > > > This is definitely possible but I'm not sure I'm going to take it as a > > matter of fact. We never hear from the people that don't have issues > > installing things so there could be a bit of a confirmation bias on which > > is more easily installed. That said, even though spidermonkey does have > > packages I agree that its definitely not turn key. And if Node provides > > binaries for a huge swath of platforms that may be more than enough for us > > to stop caring on the ease of installation issue. > > > > > > > My suspicion is Node.js simply moves so fast as a general-purpose tool > > that > > > it can or will provide everything needed for a replacement view server. > > > Should we even replace the view server? Change the protocol? Embed JS as > > a > > > NIF? All good questions. This branch will (slightly) inform those larger > > > discussions. > > > > > > Will you permit a prediction with no prior research: Node.js has a very > > > good sandboxing story. Some package out there has already exposed the V8 > > > API in a convenient way. Perhaps more people need Node.js sandboxing than > > > the size of the entire CouchDB community. The npm registry serves 100 > > > million requests per month and that number doubles every five months. > > > > > > I would like to see a clear definition of "sandboxing." I proposed a > > > definition in JIRA. Without clearly defining what it means to be "secure" > > > or "sandboxed" it is hard to give a good answer. > > > > > > > > Easy: code stored in a design doc is executed in an environment that has > > access limited to a specific set of white listed APIs in its execution > > context. > > > > My personal feeling? CouchDB has had AFAIK zero security issues with the > > > JavaScript VM. Over how many years? That is huge. Nobody comes home from > > > work and tells their spouse, "CouchDB protected my data today. Again." No > > > office has a chalkboard saying "952 days without a CouchDB security > > > breach." But they should. If Node.js cannot provide the same guarantees, > > > that is a deal breaker. > > > > > > > > +1 > > > > > > > Finally, IMO, the anonymous function issue is not CouchDB's problem. That > > > is the view server's problem. In the 1.x API, a view server must support > > > "function() {}" full-stop. Personally, I think JavaScript is a better > > place > > > to provide compatibility. Couch sends you a string. Parse the string, > > wrap > > > it in parens, wave a chicken, whatever. My implementation (optimized for > > > shipping date), creates a Function() with a body of "return (" + > > the_code + > > > ")". So it is a metafunction or something. I run that function and now I > > > have the map, reduce, filter, etc. function the user expects to run. > > > Instead, one might use Esprima to parse the source code and from there > > > anything can happen. My point (and opinion) is, the code that handles the > > > anonymous function problem should be JavaScript, not C or Autotools. > > > > > > > > > > > +1 in general. I agree with your sentiment but not on some of the > > specifics. While I think you're quite right that the place to deal with > > this issue is inside the view server itself and its not "CouchDB the > > Erlang/C/Autotools project" that should be managing this. That said it very > > much is "CouchDB the project"'s problem in that we need to provide clear > > coherent directions on exactly what works where and how to fix things. > > > > I could see this direction being a very clear "In 1.x/2.x you have to make > > minor modifications too all of your JS code" on one end of the spectrum vs > > a "We should be able to transparently upgrade your code" on the other end > > with the most likely "your code will just work if you don't use external > > helper functions". Just so long as we have a concise statement on the > > expected behavior for all of our users. > > > > > > > > > > On Fri, Jan 25, 2013 at 6:40 PM, Paul Davis <[email protected] > > > >wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > > > Iris Couch > > > > > > > > > -- > Iris Couch
