On Fri, Jan 25, 2013 at 8:51 AM, Jason Smith <j...@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.da...@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 <j...@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 <dirk...@ochtman.nl
> > > >wrote:
> > >
> > > > On Fri, Jan 25, 2013 at 12:06 PM, Jason Smith <j...@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
>
