couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Sat, 26 Jan 2013 21:37:03 GMT
On Sat, Jan 26, 2013 at 2:31 AM, Jason Smith <jhs@iriscouch.com> 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 <paul.joseph.davis@gmail.com>wrote:
>
> > On Fri, Jan 25, 2013 at 8:51 AM, Jason Smith <jhs@iriscouch.com> 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 <paul.joseph.davis@gmail.com
> > > >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 <jhs@iriscouch.com>
> > 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 <
> > dirkjan@ochtman.nl
> > > > > >wrote:
> > > > >
> > > > > > On Fri, Jan 25, 2013 at 12:06 PM, Jason Smith <jhs@apache.org>
> > > 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

Mime
View raw message