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 Fri, 25 Jan 2013 20:13:30 GMT
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