couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Fri, 25 Jan 2013 14:51:19 GMT
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.

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.

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.

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.

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.



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message