This is what this discussion is all about. The argument is that a string
description isn't really useful in the real world. Currently, this API
allows us to query integer values, which can be used as necessary by the
module.
Ryan
On Thu, 12 Apr 2001, Ian Holsman wrote:
> could you have a mpm group of functions to determine the
> capabilites of the installed MPM.
> a function to show the name of it,
> it's threading model
> and maybe a string description of the configuration of it.
>
> so for example
>
> for mpm_prefork it would be "pre-fork" as a threading model, and it would read "30
>At Start, Max of 50 (Hard: 400), ... "
> where mpm_threaded would be "pthread" as a threading model, and it would say
>something like "5 processes, each 10 threads"
>
> maybe also a set of 'cabaility' functions
>
> mpm_has_shared_mem
> mpm_has_multiple_contexts_per_process (for threaded)
>
> that way a module writer could query the MPM for what kind of capabilities it has,
>and could
> adjust it's own behavior accordingly.
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, April 12, 2001 8:38 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [PATCH] mpm_query_2
> >
> >
> > On Thu, 12 Apr 2001, Harrie Hazewinkel wrote:
> >
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > On Thu, 12 Apr 2001, Harrie Hazewinkel wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I have made a new patch for the mpm_query functionality.
> > > > >
> > > > > 1) This patch extends the information that can be retrieved.
> > > > > 2) It also allows to return an MPM_TYPE which is a string.
> > > > > This is used to provide some additional information
> > > > > about the MPM used. It even could be used by an MPM
> > > > > developper to provide an arbitrary human readable
> > > > > string which can be used for management purposes.
> > > >
> > > > -1 for returning the string from this function. It makes
> > the function
> > > > harder to read and to use. If you absolutely must have a
> > way to query the
> > > > MPM name, then use a separate function for it. Something like
> > > > ap_show_mpm() like Sander suggested yesterday.
> > >
> > > You definitly have not understood the use of it.
> > > But that does not matter. I know you act like the APACHE
> > > 2.0 police.
> > >
> > > I now start thinking that the MPM_TYPE should be an MPM_DESCR.
> > > and for what the ap_show_mpm goes it can use the mpm_query to
> > > provide the proper values. IMHO, the ap_show_mpm
> > > is a not wrapper around ap_mpm_query.
> >
> > What?!? How have I not understood the use of it? I have
> > simply said that
> > adding the ability to return a string from that function
> > makes the code
> > unnecessarily ugly. I have suggested using a separate function for
> > getting the same information that you want. I am not removing
> > functionality, I am asking to make the code and the API simpler.
> >
> > ap_show_mpm should definately not be a wrapper around
> > ap_mpm_query. if
> > you are going to do that, then just don't create ap_show_mpm.
> > The goal is
> > to keep the API simple, not to make it overly complex by
> > having two ways
> > to get the exact same information.
> >
> > Ryan
> > ______________________________________________________________
> > _________________
> > Ryan Bloom [EMAIL PROTECTED]
> > 406 29th St.
> > San Francisco, CA 94131
> > --------------------------------------------------------------
> > -----------------
> >
> >
>
>
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
