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:25:11 GMT

On Jan 31, 2013, at 17:22 , Jan Lehnardt <jan@apache.org> wrote:

> 
> On Jan 31, 2013, at 17:20 , Benoit Chesneau <bchesneau@gmail.com> wrote:
> 
>>>> 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?
>>> 
>> 
>> 
>> This is a policy we should define imo. Do we want to think to a
>> cross-platform solution today (desktop, mobile & other) and if yes we have
>> to make sure it works or will we have different solutions depending on the
>> platform. We can also just ignore that part and let it for the future with
>> the possibility to switch again. I have no strong opinion on that but that
>> something that should be decided imo.
> 
> I’d say we make that policy once we have the code. I’m totally in favour.

In addition, that’s why I like to see your rcouch improvements merged soon,
so we don’t get into these situations where CouchDB decides to do something
that breaks future compat with rcouch :)

Jan
-- 


> 
> Best
> Jan
> -- 
> 
> 
>> 
>> 
>>> 
>>>>>> 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.
>>> 
>>> +1
>> 
>>> 
>>>> A
>>>>> 
>>>> 
>>>> 
>>>> 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.
>>> 
>>> 
>>> yes just a short list while yiou were speaking about it. we indeed need to
>> have a concensus on that.
> 


Mime
View raw message