couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Branca <chewbra...@gmail.com>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Fri, 25 Jan 2013 21:38:39 GMT
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
>

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