couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Sun, 27 Jan 2013 19:49:57 GMT
On 26 January 2013 22:38, Paul Davis <> wrote:
> On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau <> wrote:
>> On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith <> wrote:

This is a great thread & I'm wholly in favour of pretty much all of it.

As is my wont, some points only slightly related to what people
already said :D. But then we'd have 4 emails instead of one.

# What is the *problem* we are trying to solve here?

We have found a new hammer, it's very shiny. But we are not on the
same page on why we need the hammer.

# My problems

1. The hurdle for beginners could be lower. I could see a future where
you can install apps as easily as:

"cpm install garden20"

and even leverage infrastructure like npm to do so.

How in the back-end we transform those ddocs into the (to us) logical
structure then becomes an internal issue. People can use npm modules
to extend and develop their ddoc capabilities.

Yes, this type of functionality exists today (commonjs modules,
couchapp/erica/kanso) but it's not as easy as we could make it.

2. Extending couchdb with JS functionality, such as routers,
authentication modules like passportjs could be npm easy. Today I
think there's a handful of folk who would be able to do that. We would
benefit hugely from making this step.

I think this is the biggest win. There are node modules for almost
anything, and a very hacker-friendly composable interface for most of
them. If we can make the integration tight, that's a huge step
forwards. Today it is definitely an additional layer, even if you use
the externals API.

3. less build issues as node comes pre-packaged on all systems. This
means swapping out couchjs for nodejs basically, re-using whatever
protocol is already in place for the view servers, and making this
Somebody Else's Problem.

4. finding a way to reduce the serialisation roundtrip cost between
erlang/JSON/native JS.  I guess that likely this is the most
significant slowdown in the whole of couch, but we don't measure this
stuff much (queue Russell). Some crazy-ish ideas:

- storing raw/compressed JSON on disk instead of erlang terms (forget
using erlang views in this case)
- finding a way to freeze & thaw v8 JS objects so that there's not
even a need to parse at all (lots of unsavoury possibilities here)
- parsing the erlang terms directly in JS (avoid the erlang term ->
JSON step) and keep both view server options

Anyway food for thought, no code attached.


View raw message