Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
References: <5033E113.90009@aldan.algebra.com>
 <2245AD18-14C9-4F86-A652-E92856B5D107@webthing.com>
 <A2FA726D-D2FF-4FA3-B382-F893207038F3@sharp.fm>
In-Reply-To: <A2FA726D-D2FF-4FA3-B382-F893207038F3@sharp.fm>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <56F54E9D-2100-4A79-ABBE-0B45F0249FCE@webthing.com>
Content-Transfer-Encoding: quoted-printable
From: Nick Kew <nick@webthing.com>
Subject: Re: Limitations of mod_dbd - single server per vhost
Date: Wed, 22 Aug 2012 12:24:12 +0100
To: dev@httpd.apache.org


On 22 Aug 2012, at 11:43, Graham Leggett wrote:

> On 22 Aug 2012, at 10:25 AM, Nick Kew wrote:
>=20
>>> =46rom reading the module's documentation, it seems, a single vhost =
can only use one DB-server (and only with one set of credentials): only =
a single DBDriver and DBDParams is possible, for example.
>>=20
>> That is by design: it is expected to meet most needs.
>> If you wants more generality, go ahead and hack it.
>=20
> This is one of the things I'd like see minimised in the server =
implementation, the inclusion of arbitrary restrictions that later have =
to be lifted.

My words you quoted are somewhat oversimplified.  The design didn't say
"we'll only allow one backend ...", it was just a case of not =
introducing
extra complexity.

The implementation needs object persistence, of the kind we have
in the per-server configuration but not per-directory.  That was the
original design constraint.

> I went through the proxy and cache implementations for httpd v2.4 and =
removed all the per-virtual-host restrictions from all directives that =
didn't require it, as too often I was approached saying "we can't use =
the cache because feature X can only be set server wide and that breaks =
site Y". Ideally directives should be per-directory or per-location, =
unless there is a concrete reason otherwise.

Indeed, I seem to recollect doing some of that for ProxyPass & family
right back in the days of 2.0, when it was indeed a bug[1]!  But that's =
a
different kettle of fish.

> My rusty memory tells me that someone submitted a patch to fix this a =
while ago?

Now that you mention it, wasn't something committed?  I think that
whatever we have is either there in the code or excluded because
there were more problems with it than anyone was prepared to fix.
But ICBW.

[1] starting with r231355 and
http://marc.info/?l=3Dapache-httpd-dev&m=3D110726027118798&w=3D2

--=20
Nick Kew=