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 19:27:28 GMT
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
>

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