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 Thu, 31 Jan 2013 10:42:36 GMT
On Sun, Jan 27, 2013 at 7:49 PM, Dave Cottlehuber <dch@jsonified.com> wrote:

> On 26 January 2013 22:38, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> > On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau <bchesneau@gmail.com>
> wrote:
> >> On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith <jhs@iriscouch.com> 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?
>

The problem on my mind is quite modest: assess the feasibility of some kind
of CouchDB+Node.js hybrid. I want to see how that changes build issues, and
just generally see how it feels.



>
> 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"
>

I am not familiar with cpm however I am not thinking at all about building
applications. In fact my goals are 100% compatibility with CouchDB 1.x.
That is why I simply swap out the couchjs program.



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

That is out of scope with regard to the nodejs_couchdb branch.


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

Yes, exactly.


> 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:
>

Frankly I think performance should be a CouchDB 2.x feature. People want to
change the view server model. People want to add more JS tooling, such as a
better signup workflow. I have no opinion about all of that. However my
work should inform those discussions because it elucidates how those tools
might be implemented, and it might hint at some obviously good or bad
directions.

-- 
Iris Couch

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