From user-return-5431-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Jul 08 12:12:20 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 11691 invoked from network); 8 Jul 2009 12:12:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Jul 2009 12:12:20 -0000 Received: (qmail 63489 invoked by uid 500); 8 Jul 2009 12:12:29 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 63410 invoked by uid 500); 8 Jul 2009 12:12:29 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 63400 invoked by uid 99); 8 Jul 2009 12:12:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Jul 2009 12:12:29 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [91.199.167.26] (HELO server05.streamservice.nl) (91.199.167.26) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Jul 2009 12:12:17 +0000 Received: from [82.75.192.50] (helo=laptoptruus) by server05.streamservice.nl with esmtpa (Exim 4.69) (envelope-from ) id 1MOW07-0000mY-U8 for user@couchdb.apache.org; Wed, 08 Jul 2009 14:11:52 +0200 From: "Stream Service || Mark Scholten" To: References: <002c01c9ff2a$8bfc0af0$a3f420d0$@nl> <2d8fb9950907071104nc3a7ed4t312566619a022a16@mail.gmail.com> <20090708081320.GA25290@tumbolia.org> <2d8fb9950907080226v771a42bbo54cb11deafc8e67e@mail.gmail.com> <20090708093351.GB26926@tumbolia.org> <2d8fb9950907080453w4e6aa552nb446817fc0490f3c@mail.gmail.com> <007301c9ffc3$537a9d60$fa6fd820$@nl> <2d8fb9950907080508p318c82b7nae0c23da2e4da8ee@mail.gmail.com> In-Reply-To: <2d8fb9950907080508p318c82b7nae0c23da2e4da8ee@mail.gmail.com> Subject: RE: FW: CouchDB shared hosting Date: Wed, 8 Jul 2009 14:11:52 +0200 Message-ID: <007401c9ffc5$475b8470$d6128d50$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn/xPGrPI9Oov/CRhmUhqZr51XHWwAABxpw Content-Language: nl X-Virus-Checked: Checked by ClamAV on apache.org We are not even allowed to give each user a separate IP address on our = shared hosting platform. If they have a VPS or dedicated server they get = a dedicated IP of course. With IPv6 we can give each user multiple IP = addresses and we probably do it per domain or subdomain with IPv6 (when = we have it). -----Original Message----- From: Sergey Shepelev [mailto:temotor@gmail.com]=20 Sent: woensdag 8 juli 2009 14:09 To: user@couchdb.apache.org Subject: Re: FW: CouchDB shared hosting So you're not giving each user separate IP address? On Wed, Jul 8, 2009 at 3:57 PM, Stream Service || Mark Scholten wrote: > Please note: > Using multiple IP addresses just because it is easy for users isn't a = real option. If they need to be able to connect to it from another = location it would give a problem (only 1 "public" IP/server, unless we = work with SSL certificates) is allowed by RIPE for as far as I know. = With IPv6 this is of course not a problem. > > -----Original Message----- > From: Sergey Shepelev [mailto:temotor@gmail.com] > Sent: woensdag 8 juli 2009 13:54 > To: user@couchdb.apache.org > Subject: Re: FW: CouchDB shared hosting > > On Wed, Jul 8, 2009 at 1:33 PM, Noah Slater wrote: >> On Wed, Jul 08, 2009 at 01:26:07PM +0400, Sergey Shepelev wrote: >>> > He clearly means programmatic access, instead of via a GUI = interface. If you >>> > had spent any time administrating a shared access computer system, = you would >>> > realise how important this question is. >>> > >>> >>> Script changing http server config and making it reload config is a >>> programmatic access. I had spent quite time administering frontend = http server >>> and that's why i'm talking about such scripts. >> >> I'm sure, but your original reply was quite flippant: >> >>> In fact, there is no such thing in the world, that can't be done = "with >>> commands, automatically". >> >> Without a lot of experience, it is easy to imagine that there are = some things in >> CouchDB that cannot be done programmatically. I know that for one of = the Java >> based companies I'm involved in, a lot of our back-end systems = require complex >> GUIs to change configuration settings - which is a total nightmare. > > Sorry for trolling, but overcomplex systems with GUI configurators are > so typical in Java world, sure you should expect a nightmare. :) > >> >>> Because it's the same as if CouchDB would run one database per = instance. You >>> just run another thin instance for another database and everything's = fine. >>> Multiplexing databases into one instance only makes sense (in my = opinion) if >>> we have really thousand of clients per one box and everyone = occasionally uses >>> their databases. In that case even lightest instances would fill up = memory. >>> Moderate database per box distribution solves this problem. >> >> Each CouchDB server needs to live on a different port, and this = sounds >> problematic if you're offering CouchDB instances to paying customers = who expect >> them all to live on the same port. You could do some complex proxy = setup, but >> that doesn't sound trivial to automate. > > Or, on different ip address which doesn't sound that problematic. Is = it? > >> >> Best, >> >> -- >> Noah Slater, http://tumbolia.org/nslater >> > >