From: <[EMAIL PROTECTED]>
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: <[EMAIL PROTECTED]>
> > 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
