> > > I would prefer to not modify the API
> > > unless we need to now.
>
Agreed. In fact haven't we been doing that for a good while now?
> >
> > Who determines the need?? I see a use and need for it. Does that count??
> > Or since I am not an hard-core Apache developper or ASF-member, it does
> > not count??
>
???? Duh?
>
> The need is determined by consensus on this list. If you can convince the
> people on this list that there is a need, then the change will be made.
> Those are the same rules that we all live by. I can't just make a change
> to the code. If anybody on this list has a problem with the change, they
> can question that change, and I have to back it up.
>
As has been done a few times :)
>
> > > 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 server string gives way more information that needed here.
>
Why is that a problem? Let the client get the parts they want? Never known
providing too much information to be a problem...
> >
> > The problem is that since we do not standardise the capabilities
> > the 2 capabilites Ryan would add are not enough. In operational
> > environments it is mostly very usefull to know its name or
> > vendor of some piece of software, since it may have behavior
> > (for instance seg-faults) under certain conditions. This is indeed
> > the gray area, but for operators this is part of experience.
> > More like, ah, that machine we see this, which version does it have??
> > Ok, that happens more, we fix it this way.
>
Server string seems like it does this already, and if it doesn't it's a simple
change. Don't really see the point of this, sorry.
>
> Fine, yes it might be useful to get the MPM name. If that is the case,
> then use a separate function to get the name. Do not overload the
> MPM_query function.
+1 KISS
david
