On Tue, Sep 28, 2010 at 9:55 PM, Paul Davis <[email protected]> wrote: > On Tue, Sep 28, 2010 at 3:49 PM, Benoit Chesneau <[email protected]> wrote: >> On Tue, Sep 28, 2010 at 9:41 PM, Paul Davis <[email protected]> >> 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 network. 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.
