Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 17304 invoked from network); 28 Sep 2010 20:09:19 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Sep 2010 20:09:19 -0000 Received: (qmail 55991 invoked by uid 500); 28 Sep 2010 19:42:39 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 55955 invoked by uid 500); 28 Sep 2010 19:42:38 -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 55943 invoked by uid 99); 28 Sep 2010 19:42:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Sep 2010 19:42:38 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.214.180 as permitted sender) Received: from [209.85.214.180] (HELO mail-iw0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Sep 2010 19:42:28 +0000 Received: by iwn8 with SMTP id 8so34347iwn.11 for ; Tue, 28 Sep 2010 12:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=qRB/PElMHDRV3mQEqRL3G5q1vsqtm2s+LsbUULs0Uw0=; b=Ky30rl8FDXJ0wEscAUZaDa690JDLmyMHffoiC/WltgeQxquIKz4GgaSMEhijrO+zwD h3/7vt2zhnIdlRre5SO6BzVV7xU78d8wLpC2DATpaarRc9fX3Uq8o/skEuJT1OOprCAB JDBPH3Vx/mJy9k8q0G7qE/z9XeP/RdS8HdLxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=hhjW8f3fl/mgKqUV7wxW7K6Ed7EPGpZNOJ9F+b6rb52lmBiBZ5JuVmX1QFj1RJSzS9 IiotVODs01sMsUT7cL879ojgm5geqDwg9QRmUufZiiu6Iiel8exyeossqYrUV/RRYz8H 9TaJJnBLZHyDvImzlOReX0YhnUXVSP5NADBVg= Received: by 10.231.19.136 with SMTP id a8mr445220ibb.86.1285702927002; Tue, 28 Sep 2010 12:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.194 with HTTP; Tue, 28 Sep 2010 12:41:25 -0700 (PDT) In-Reply-To: References: <20100925173757.C583A23889ED@eris.apache.org> <79D74715-4889-4613-BEE3-B7905EDA6532@apache.org> From: Paul Davis Date: Tue, 28 Sep 2010 15:41:25 -0400 Message-ID: Subject: Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Sep 28, 2010 at 3:21 PM, Benoit Chesneau wrot= e: > On Tue, Sep 28, 2010 at 9:08 PM, Paul Davis = wrote: >> On Tue, Sep 28, 2010 at 2:59 PM, Benoit Chesneau w= rote: >>> On Tue, Sep 28, 2010 at 7:26 PM, Filipe David Manana >>> wrote: >>>> Looks like I started an avalanche. >>>> >>>> Why not 2 files, like: >>>> >>>> var/run/couchdb/couch.http >>>> var/run/couchdb/couch.https >>>> >>>> each one would be a CSV (or tab separated, or new line, or whatever) >>>> list of =A0host:port elements. >>>> ? >>>> >>> >>> About this issue, what is the usecase of having all urls on fs ? >>> Couldn't =A0just have one for open and let app see in /_config ? >>> >>> - benoit >>> >> >> And which one do we put on the file system? > The first one, apps won't care, we only run one couchdb with same data > on it. If we run real virtual hosting with different data, the pb > would be different > > >> >> Also, in real life, I doubt most people will ever have more than two >> entries in this file. Right now, its not even possible to have more >> than two. > > and for above reason, we don't really need to care. Only one ip is enough= . > What if the client doesn't have access to the arbitrarily chosen address? There's no way that CouchDB can guess at all the possible network configurations to try and make that choice. Even if a random address works 99% of the time, why make a decision to break things for the 1%? Even if we list multiple address the client is free to just try the first one and have it work 99% of the time. I'm not sure what you mean by virtual hosting and different data or what problems that might introduce. HTH, Paul Davis