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 Sat, 26 Jan 2013 08:31:37 GMT
Paul, we are in broad agreement, so therefore you are correct by
definition. :)

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.



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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message