Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <02d601c0c2b8$5a9db5b0$94c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <new-httpd@apache.org>
Subject: Fw: [PATCH] mpm_query
Date: Wed, 11 Apr 2001 13:50:49 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: <rbb@covalent.net>
Sent: Wednesday, April 11, 2001 1:36 PM


> Did you mean to just send this to me?

No... would love to know how you escape new-httpd munging to muck up my
replies :-)  Either that or there is a ghost in the machine.

For everyone's benefit...

> On Wed, 11 Apr 2001, William A. Rowe, Jr. wrote:
> 
> > From: <rbb@covalent.net>
> > Sent: Wednesday, April 11, 2001 1:24 PM
> >
> >
> > > On Wed, 11 Apr 2001, William A. Rowe, Jr. wrote:
> > > >
> > > > Beyond that, there is nothing wrong with being informative :-)
> > >
> > > My problem with the name, is that it requires chaning the API or adding a
> > > new API to deal with a string.  I would prefer to not modify the API
> > > unless we need to now.  Not that I am dead-set against changing the API, I
> > > just want a good reason before we do so.  I don't believe that allowing
> > > modules to query the name of the MPM is a good reason.  IMHO, the correct
> > > way for somebody to get the name of the MPM, is to use the ServerString.
> >
> > The API will continue to _grow_.  It's not stone till we call it gold (and
> > even then...)
> >
> > There is a difference between growing and changing.  Add a function, no
> > problem.  Change an existing declaration, well, then have a damn good reason,
> > and I agree this isn't sufficient for changing.
> 
> I disagree that this is generally useful information, or that it is a good
> reason to add a function.  Remember that every API we add means added
> complexity for module developers.

One last through... why doesn't the mpm become the 2nd level server version
identifier.  I believe we will appreciate knowing which modules are adopted
over the course of time.  This satisfies versioning, 3rd party mpms, and
informative feedback without modifying the api.

Bill