Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 43B39E39D for ; Thu, 31 Jan 2013 16:20:36 +0000 (UTC) Received: (qmail 12536 invoked by uid 500); 31 Jan 2013 16:20:35 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 12479 invoked by uid 500); 31 Jan 2013 16:20:35 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 12471 invoked by uid 99); 31 Jan 2013 16:20:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2013 16:20:35 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates 209.85.223.178 as permitted sender) Received: from [209.85.223.178] (HELO mail-ie0-f178.google.com) (209.85.223.178) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2013 16:20:27 +0000 Received: by mail-ie0-f178.google.com with SMTP id c13so2558901ieb.9 for ; Thu, 31 Jan 2013 08:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=UsLNgcHqKrTgJeyirAD7zFH9P8LhdrdV+3tZjk9LPtU=; b=dVmmrawCdRVvI4HVsdTTISMULC8KLCh5in7n/YLyNH9QzURjIyLeiKHoYP0CfGwT2z e7wcTte53oXBSJETtzw75qc2i8JaiLGHte5+vj0crjBiG7jqfq1HYrECJA/smgc5CbCD UE8/r8saZpWi4dBV/n8MGB8X9CxHX2AYndUt7NDhzNr/P02ahRAua3TxoTzHgeX2gWwY ZNH9Ldna9wi1O5kHDG1kCFPSnxtXwdNefqou6k8zi2kaPh2NZ27jl+xTKC217LNvV1dN CD7rJCTSlj9W80izPEGHE300mSjJCq36vrCz5T47tbR7U4ckhHb0DS6RXQueVDRel8BQ PHGA== MIME-Version: 1.0 X-Received: by 10.50.187.169 with SMTP id ft9mr1627471igc.25.1359649206818; Thu, 31 Jan 2013 08:20:06 -0800 (PST) Received: by 10.64.29.13 with HTTP; Thu, 31 Jan 2013 08:20:06 -0800 (PST) In-Reply-To: <7513187B-EBA3-45A0-A4F0-F014D6BEFE20@apache.org> References: <5102B439.10500@lymegreen.co.uk> <8A160546-A117-48CE-94B5-3CAC66EDE3ED@apache.org> <7513187B-EBA3-45A0-A4F0-F014D6BEFE20@apache.org> Date: Thu, 31 Jan 2013 17:20:06 +0100 Message-ID: Subject: Re: Branch to switch from SpiderMonkey to Node.js From: Benoit Chesneau To: "dev@couchdb.apache.org" Content-Type: multipart/alternative; boundary=14dae9340575fdd63104d497ffa7 X-Virus-Checked: Checked by ClamAV on apache.org --14dae9340575fdd63104d497ffa7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > 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. > > >>> 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 matte= rs > >> 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=92s 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=92d file this for nice to have someday. > > > yes just a short list while yiou were speaking about it. we indeed need t= o have a concensus on that. --14dae9340575fdd63104d497ffa7--