On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> From: "dean gaudet" <[EMAIL PROTECTED]>
> Sent: Sunday, February 25, 2001 6:51 PM
> > On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> > > From: "dean gaudet" <[EMAIL PROTECTED]>
> > > Sent: Sunday, February 25, 2001 6:14 PM
> > > > On Fri, 23 Feb 2001, Rodent of Unusual Size wrote:
> > > >
> > > > > Then let us call it 'WorkersPerChild,' confound it! Or whatever
> > > > > name we use for 'entity capable of serving a request'!
> > > >
> > > > +1000.
> > >
> > > Make that +1001, if we are avoiding the Thread/Process labels, then ignore
> > > the danged things. Accept in all mpms - and emit a warning that goes something
> > > like "WorkersPerChild has no effect in mpm_pthread". No vi httpd.conf required.
> >
> > hrm i'd rather the directives just not exist in mpms in which they make no
> > sense. there's no reason to maintain backwards compat with 1.3 config
> > files... and there's probably a <IfModule> incantation you can use to
> > differentiate your multiplatform config files (if any such thing even
> > exists, i can't really imagine it myself).
>
> I feel I've lost that argument two weeks ago. Folks want 'abstract' concepts so
> they don't have to tweak anything between firing up a pthread, pervhost, etc.
>
> Granted, advanced concepts don't belong everywhere. But if we can't agree that
> a process is a process, and a thread is a thread, and we want things more generic
> for (??? I'm still not clear), then this is probably a legitimate no-op.
>
> Agreed on 1.3 non-compatibility, disagree based on the list's take on the issue that
> we don't need to be reasonably compatible between mpm's. If the user wants to play
> advanced pervhost games, let those be in <Module > blocks.
I'm with Dean, and against the list, on this one. Stop trying to make all
the MPMs look alike. They aren't the same, and trying to make them the
same is a bad thing. I agree 100% that if a directive is in two MPMs, it
should act the same way, but do not tell me that in all MPMs, I have to
have the same directives.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
