On Wed, 2006-13-12 at 17:30 +0100, Paul Fee wrote:
> > ----- Original Message -----
> > From: "Guy Hulbert" <[EMAIL PROTECTED]>

<snip>
> > 
> > Why do they need more than one ?
<snip>
> Hi Guy,
> 
> The main motivation is that I don't want to dictate install location to 
> people that are using 
> my builds of httpd.

But you still have to dictate the platform: CPU, OS and OS
version.  /usr/local, /opt, or /srv are standard places to add software.

> 
> Secondly, I have multiple people testing httpd and my module.  I want to 
> increase machine utilisation
> and allow multiple installations on one box.  It may be possible to arrange 
> that they share a common 
> httpd but ideally each installation would be self contained.
> For example different httpd versions may be built with different options.

Debian builds almost all the modules dynamically loadable.  You could
still run multiple copies with different modules loaded.

> 
> The only conflicting resource that different instances must avoid contention 
> over should be the TCP port
> that httpd listens on.

Exactly.  Apache has a built-in mechanism (virtual hosts) to multiplex
this resource.  If you enable htaccess (not recommended -- see
apache.org -- but the issue is worse for your scenario) then different
features can be enabled by the end users ... or you can use 'include'
and let them configure things themselves.

> 
> Another scenario would be a httpd server in active service and the need to 
> install a new version 
> (in a different directory) for testing without removing the active version.  
> It would be good if 
> httpd had the option to be built without advanced knowledge of its install 
> location.

Other people responded with generic solutions to this as I expected they
might.

> 
> Without eliminating absolute paths, I find myself heading down the path of OS 
> visualisation, which 
> to me seems very heavy weight to install multiple instances of one 
> application.

Apache is a pretty heavy application.  Xen still requires multiple IP
addresses but RAM and DISK are *cheap* and modern CPUs are *fast*.

> 
> Thanks,
> Paul

-- 
--gh


Reply via email to