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:11:45 GMT
Russell, thanks for you comments on the ticket.

For the record, I fixed some i/o bugs in couchjs and most of the test suite
is passing on my branch now. I have nearly achieved phase 1.

I think you probably agree, in a situation like this, the only acceptable
approach is the whitelist. I think it might be easy to disable i/o in
Node.js, because it is easy to control what is in scope for the guest code.
Without access to require() or the fs module, how can code perform i/o?
Note, since the stakes are high, we must *confirm* this hypothesis, of
course.

An interesting exception and challenge for the "no I/O" rule is that of
course the entire implementation of view servers is via message passing
over stdio.

I agree with your comments about npm. Three points:

1. Right, it is inappropriate or out of scope to talk about using
modules/packages/npm from the view server. Besides huge security issues, it
is only marginally useful within the CouchDB 1.x API. So much of the API is
stateless and pure-functional programming.

2. One reason I want to try Node.js (rather than V8) is to open the door to
users extending CouchDB and/or building applications with full-on arbitrary
Node.js code--totally separate from the view server API: maybe a version
2.x discussion.

3. Besides security, if someone could demonstrate a great performance gain
by e.g. embedding V8 in Erlang then that would be a strong argument against
Node.js. I am not holding my breath. We could extend the view server
protocol to "upgrade" from stdio to SysV or POSIX shared memory and get a
similar performance boost. The Erlang side would be a NIF and the Node side
would be a native module--so, C code talking to C code.


On Fri, Jan 25, 2013 at 9:38 PM, Russell Branca <chewbranca@gmail.com>wrote:

> Getting a spec together is a good next step, I'll update COUCHDB-1643 with
> some ideas.
>
> One distinction that would be useful, is what functionality is needed in
> the view engine for just map/reduce, versus user defined functionality in
> filters/validate/update/show/lists. I'm intrigued by the idea of a fast DSL
> on top of Erlang for views, and then making it easy to have node.js
> applications for the rest of the pieces, and keeping those separate.
>
>
> -Russell
>
>
> On Fri, Jan 25, 2013 at 12:13 PM, Jason Smith <jhs@iriscouch.com> wrote:
>
> > Wow, thanks for so much feedback, Russell!
> >
> > Unfortunately, libmozjs185 is also "a make away" I think.
> >
> > The V8 vs. Node discussion is premature until we clearly define the
> > requirements. What exactly is this "sandbox"? What guarantees or
> invariants
> > does it ensure? I have proposed a specific feature list in COUCHDB-1643.
> >
> > Without a spec, we sound like this:
> >
> > Salviati: I cut three thousand lines of code and kept 100% compatibility.
> > Simplicio: Yes, but your implementation does not have a "sand box."
> > Salviati: What is a "sand box"?
> > Simplicio: A "sand box" is that which V8 can provide, but which Node.js
> > cannot.
> > Salviati: But you can write Node modules in C which call the V8 API.
> So...
> > Simplicio: Sandbox!
> > Salviati: But--
> > Simplicio: SANDBOX!
> >
> >
> >
> > On Sat, Jan 26, 2013 at 2:27 AM, Russell Branca <chewbranca@gmail.com
> > >wrote:
> >
> > > Both Node.js and V8 are a make away, so the question is what else each
> > > brings to the table.
> > >
> > > I'm of the opinion that the big win of Node.js is npm. I would love to
> > see
> > > CouchDB extensible by npm modules. I've done some experiments along
> those
> > > lines, but the problem comes back to sandboxing. As you pointed out
> > Jason,
> > > CouchDB's javascript security has not been an issue, because the
> > > SpiderMonkey sandbox is solid. Hopefully someone with deeper knowledge
> of
> > > Node.js than myself will prove me wrong, but I haven't found a way to
> > > securely sandbox it and still allow the use of require for npm modules.
> > >
> > > Couple of alternative ideas:
> > >
> > > Option F: Distinguish between core "database" level functionality and
> > > "application" level logic.
> > >
> > > - The internal view engine needs to be simple, efficient and secure.
> Have
> > > this use V8 directly or a DSL on top of Erlang.
> > > - Abstract CouchApp level logic from the core view engine. Things like
> > list
> > > and show functions are perfect for Node.js and npm. I would love to see
> > > this extended further to make it even easier to create user defined
> > > functionality. There are so many common patterns, like the user
> > > registration thread that popped up yesterday, where the current
> approach
> > is
> > > to build a little external service, that in my opinion would be better
> > > served by a more capable CouchApp engine. I'm not saying we should try
> > and
> > > replace all potential application level logic, but at the very least
> add
> > in
> > > a concept of a "worker" functions that can filter on different event
> > types
> > > (new user, new doc, updated doc, failed validation function, etc etc)
> and
> > > execute some user defined function.
> > >
> > > There are admittedly problems with this approach. Where do filters,
> > > validation functions and update handlers go? This would also require
> > > depending on both V8 and Node.js, which I think is not as big of a
> > problem
> > > if the CouchApp engine is structured in a way to be replaceable with
> > other
> > > implementations.
> > >
> > > Option G: Make all user defined functionality execute in an isolated
> > > context using a remote protocol, and basically turn it into a remote
> > > service. This would make it even easier to build custom engines, but
> has
> > > some interesting properties like allowing you to have the engine
> running
> > on
> > > a separate server. Or fun stuff like spinning up a larger EC2 instance
> > when
> > > you need to rebuild a view, and then rolling back down when the full
> view
> > > build is done.
> > >
> > > Option H: Build something like JInterface for Javascript, creating a
> > stand
> > > alone Javascript node and switching over to message passing for all the
> > > jobs. This has some interesting properties for bulk and parallel view
> > > builds.
> > >
> > >
> > > I'm glad to see this conversation coming along. Jason, cool stuff,
> thanks
> > > for taking the initiative on this!
> > >
> > >
> > > -Russell
> > >
> > >
> > > On Fri, Jan 25, 2013 at 10:01 AM, Jason Smith <jhs@iriscouch.com>
> wrote:
> > >
> > > > Hi, David. Yes, you make very good points. I even think you (and
> > Benoit)
> > > > may be ultimately correct
> > > >
> > > > I dispute that Node.js is V8. Node is not V8. Node.js is a direct
> link
> > to
> > > > God. When I pray to God in the JavaScript language, God moves
> electrons
> > > > around inside my computer. He writes files to my disk, and He sends
> > > packets
> > > > out my Ethernet cable.
> > > >
> > > > A thought experiment: Find some computer power users or sysadmins.
> > Break
> > > > them into two groups, with one task each:
> > > >
> > > > 1. "Install Node.js on your computer, by any means"
> > > > 2. "Install V8 on your computer, by any means"
> > > >
> > > > Which group would self-report more success? Which group would
> register
> > > more
> > > > frustration?
> > > >
> > > > That is the sort of question I hope to answer (or at least supply
> some
> > > > data). With any luck I can falsify my theory and theology.
> > > >
> > > >
> > > > On Fri, Jan 25, 2013 at 11:35 PM, david martin <
> > > > david.martin@lymegreen.co.uk
> > > > > wrote:
> > > >
> > > > > On 25/01/13 11:18, Jason Smith wrote:
> > > > >
> > > > >> 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.
> > > > >>
> > > > > According to Wiki
> > > > >
> > > > > "Node.js is a packaged compilation of Google's V8 JavaScript
> engine,
> > > the
> > > > > libUV platform
> > > > > abstraction layer, and a core library, which is itself primarily
> > > written
> > > > > in JavaScript."
> > > > >
> > > > > "We still depend on an obscure VM ( so V8 is an obscure VM although
> > it
> > > is
> > > > > embedded in Node.js ) with a quirky build system."
> > > > >
> > > > > Get rid of all quirky build systems, use rebar which builds
> > everything
> > > > AND
> > > > > produces an installable relocatable executable package containing
> > > Erlang
> > > > VM
> > > > > and V8  VM and C routines as NIF's where required for speed.
> > > > >
> > > > > So Node "is" V8 plus a lot more which is not required
> > > > >
> > > > >
> > > > > --
> > > > > David Martin
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Iris Couch
> > > >
> > >
> >
> >
> >
> > --
> > Iris Couch
> >
>



-- 
Iris Couch

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