couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb:
Date Tue, 28 Sep 2010 20:05:51 GMT
On Tue, Sep 28, 2010 at 9:55 PM, Paul Davis <> wrote:
> On Tue, Sep 28, 2010 at 3:49 PM, Benoit Chesneau <> wrote:
>> On Tue, Sep 28, 2010 at 9:41 PM, Paul Davis <> wrote:
>>> 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.
>> indeed.
>> So let' let the client doing the choice itself. I think that's indeed
>> case where there will be more than one will be rare. Put all urls on
>> different lines may be more "unix".
> I'm confused, are you agreeing that we need all the address on the
> file system now?

If we have a real usecase for it yes. I don't think we need that. Just
having a local ip would be enough. ip associated to localhost or local

My question is more, is there any use case where we would have more
than one ip with a random port ? If not in which case the app couldn't
read the ini ?

> Still confused. The basic premise of a vhost is to demultiplex
> incoming requests (that share a single transport) and forward them to
> separate resources. Ie, forwarding vhosts to different databases. If
> each vhost had its own ip:port pair, they wouldn't be vhosts, just
> hosts. And further, I don't think I'd be in favor of such a feature as
> the technical debt seems a tad high for the benefit.
so I said "if we were" . Just described my idea. I've no opinion on
such thing, just contemplated it sometimes ago.

View raw message