couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 15:43:57 GMT

On Jan 31, 2013, at 16:37 , Benoit Chesneau <> wrote:

> On Thu, Jan 31, 2013 at 4:17 PM, Jan Lehnardt <> wrote:
>> On Jan 31, 2013, at 15:52 , Benoit Chesneau <> wrote:
>>> On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith <> wrote:
>>>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <
>>>>> wrote:
>>>>> That whole process sounds like not a lot of fun.
>>>> Right. That is kind of my point. CouchDB is a JavaScript thing, and
>>>> nowadays people have a very well-adopted and well-understood JavaScript
>>>> engine on their computers. Maybe it should just use that.
>>> couchdb is not a javascript thing, This is a database in which one and
>> the
>>> default engine for M/R is using the language javascript.
>>> Not all developers have nodejs installed. None of my servers have it.
>> The question is not if you server have it, but whether you could install a
>> compatible version easily.
>> I’d love to hear if you or others are not covered by
> Well this is the question somehow. Today when I release rcouch or modified
> bigcouch releases I can build them statically. I then only distribute the
> release without any other dependencies than the system and without
> requiring more rights than a user have most of the time. If not I have to
> make sure I have the correct nodejs etc.

Why can’t you bundle Node in rcouch?

> Also the point is that nodejs isn't so widely deployed or already insyaled
> that some say.

Yes, I get that. But I contest that premise. The only thing that matters
is whether Node is *available* on these systems.

* * * 

I’d like to agree with everyone on the minimal requirements that technically
need to be vetted before we can make a switch. Then see if we can reach that,
and if we do, agree to switch. If we can’t agree on the first thing, all
this discussion is moot. Part of the minimal requirements can be "make sure
that in a later step we can still do X (like embedding or bundling the JS env)",
but I don’t think we have to have definite answers for these things today,
as long as we don’t block them.


View raw message