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:34:23 GMT
On Sat, Jan 26, 2013 at 2:11 AM, Jason Smith <jhs@iriscouch.com> wrote:

> 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.
>
>
Not only no I/O but also accidentally keeping state between invocations as
well.


> 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.
>
>
+1


> 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.
>
>
While related I think this is a different discussion. For the view server I
think we should be looking at creating our sandboxed/whitelisted execution
environment in a node.js process. Once/if we have a hard dependency on
node.js then I think users/community will be able to go hog wild on
creating a standard for an arbitrary node.js app server thinger in front of
CouchDB and then we can get rid of all the various couchapp bits.


> 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