On Wed, 17 May 2000, Gunther Birznieks wrote:
> At 11:18 AM 5/17/00 +0300, Stas Bekman wrote:
> >On Wed, 17 May 2000, Gunther Birznieks wrote:
> >
> > > I am curious as to why you don't care for 20 different apaches? If you use
> > > a mod_proxy front-end, it should be relatively easy to manage 20 different
> > > apache's on the backend, especially if you use variables to start them
> > > up. There is another command line parameter that can be used to trigger
> > > different code in the same conf file (so that they start on different
> > ports
> > > for example)...
> > >
> > > In addition, a solid part of testing mod_perl modules consists of running
> > > in single process mode (ala -x parameter)) -- which is invaluable for
> > > finding cached code conflicts.. You won't be able to do this if
> > everyone is
> > > using the same apache.
> > >
> > > BTW, this would be a good addition to the guide -- how to manage a
> > mod_perl
> > > development environment with more than 1 developer (eg 20 in your case)
> >
> >Both questions are already answered in the guide:
> >
> >Kees' original:
> >http://perl.apache.org/guide/modules.html#Apache_PerlVINC_set_a_differe
> >
> >Gunter's suggestion:
> >http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E
>
> :)
>
> Excellent!
>
> One thing though is that both these suggestions actually tie together to
> solve a practical problem: Managing Multiple Developers yet are located in
> two different chapters. I think these sections belong where they do, but
> perhaps a separate discussion linking these sections (and any other
> relevant ones) would be useful.
These two are disconnected in fact. Since when you develop the code you
need just a few processes per developer, you start a separate server for
each developer -- and that's what the last link suggests. It shows how to
use the front end machine to solve the problem when all the servers are
running on the same machine.
There is no reason of runing vurtual hosts for each developer, different
ports solve this issue much better and simpler.
Of course I'd be glad to document other approaches if you will to share.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
