couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 16:12:45 GMT

On Jan 31, 2013, at 17:08 , Benoit Chesneau <bchesneau@gmail.com> wrote:

> On Thu, Jan 31, 2013 at 4:43 PM, Jan Lehnardt <jan@apache.org> wrote:
> 
>> 
>> On Jan 31, 2013, at 16:37 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>> 
>>> On Thu, Jan 31, 2013 at 4:17 PM, Jan Lehnardt <jan@apache.org> wrote:
>>> 
>>>> 
>>>> On Jan 31, 2013, at 15:52 , Benoit Chesneau <bchesneau@gmail.com>
>> wrote:
>>>> 
>>>>> On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith <jhs@iriscouch.com>
>> wrote:
>>>>> 
>>>>>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <
>>>> paul.joseph.davis@gmail.com
>>>>>>> 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
>>>> 
>>>> 
>>>> 
>> https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
>>>> 
>>>> 
>>>> 
>>> 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?
>> 
> 
> 
> Was thinking about it, there is nothing that prevent it i guess, but the
> toolchain needed is quite more expensive. We need either python or cmake to
> build nodejs today if I remember, so it imply more tooling. Just a matter
> of organising stuff. This for desktop. It is also a lot more complicated
> than just integrating v8.

Definitely. I am definitely interested on getting the whole packaging story
straightened out.


> On IOS and Android there isn't any stable release of nodejs today which can
> be problematic. It is easier with v8 now but this is another topic.

But we agree that this is out of scope for now?


>>> 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.
>> 
> 
> Well not really. Some users have specific requirements for dependencies.
> For example lot of centos/rhel users can't install anything coming outside
> legal repos.

Right, that’s why I am asking for a list of available node versions on these
systems that we want to target with future versions of CouchDB.


> Anyway useful link. (I was just thinking that if we jump into
> node or v8 we can provide q tool discovering such resource for the user on
> install, a `check-dependencies`script) .

That’d be neat!


>> * * *
>> 
>> 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.
>> 
> 
> 
> My requirements  for a first try are:
> 
> - sandboxing: no I/O accepted by default, no global variables, or functions
> that leak content

Cool, thanks.

> - embed in our source code so we don't rely to external for that. and don't
> ask to the user to check outside

I think this one is debatable, but possible with Node (as opposed to SM).
I’d file this for nice to have someday.





Mime
View raw message