couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 12:55:34 GMT
On Thu, Jan 31, 2013 at 5:52 AM, Randall Leeds <> wrote:
> On Thu, Jan 31, 2013 at 2:42 AM, Jason Smith <> wrote:
>> On Sun, Jan 27, 2013 at 7:49 PM, Dave Cottlehuber <> wrote:
>>> 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 <>
>>> 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.
> That's not a problem statement, but it implies there's a problem with
> "build issues".
>>> 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.
> I'm guessing this is an imaginary "couchdb package manager". Something
> like a .cpmrc would list the couch that packages might get installed
> to (whether they be couchapps or other addons).
>>> 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.
> Good. I think that's wise.
>>> 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.
> I'm not sure I believe that Node is actually more widely packaged than
> SpiderMonkey. However, there is a good place to go for a summary of
> availability of NodeJS via package managers here:
> I could find no equivalent for SM.
>>> 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.
> I think there may be great opportunity for some CLI management tools,
> likely using node, which are independent of the couchjs implementation
> but, if bundled, would suggest that node all the way through would be
> more sensible.
> Nice work, Jason. I'm still hesitant, but I also think this could be a
> good direction.
> For example, another direction to explore, which may be *even simpler*
> than trying to include V8 or demand node be installed, is just to
> bundle SpiderMonkey 1.8.5 in the source and drop support for previous
> versions. Leave it to distros to link to their version *if they have
> one* if they care about not bundling dependencies.
> I believe this is possible, but I would want to run it by legal. I
> reason that since js1.8.5 is licensed under MPL 1.1 [1] and Section 6
> makes clear that code may be used under the terms of subsequent
> license versions*. That means we could include js1.8.5, replace the
> MPL 1.1 with MPL 2.0 [2], include MPL2's Exhibit B "Incompatible With
> Secondary Licensenses" Notice (thereby revoking the GPL
> compatibility), and bundle it with Apache CouchDB. +
> * One question would be about how the MPL 1.1 says only "Netscape" may
> issue new versions, but the MPL is now owned and maintained by
> Mozilla, does that mean that MPL 2 counts in the Section 6 clause. I
> suspect the answer is "yes".

That whole process sounds like not a lot of fun.

> + Standard IANL disclaimer applies heavily.
> [1]
> [2]

View raw message