Re: MPM documentation

[Joshua Slive <sl...@finance.commerce.ubc.ca>]

[Sorry for the cross-post, I am copying this into new-httpd because these
are all combined documenatation and source-code policy issues.]

On Fri, 17 Nov 2000 rbb@covalent.net wrote:

> 
> > 1. mpmt_pthread is a really crappy name for a module.
> 
> Agreed.  It is even worse because it doesn't rely on pthreads
> anymore.  Please, if anybody can come up with a better name, we need it.

I don't think we will ever find a name (less than 500 characters) that
will completely describe the module.  That is what documentation is for.  
But, I think that mpm_multithread, mpm_hybrid, mpm_threadproc, or even
mpm_wilbur would be better than mpmt_pthread.  None of these names
distinguish between this module and dexter, but, as I said, you can't
describe everything in a name.

As far as a general rule, I say that the name should start with
mpm_ (just like other modules always start mod_) and should be short
and relatively easy to remember and spell.

> > 4. I believe that there are going to be many different MPMs using the
> > same directive names.  Unless we can guarantee that all the MPMs will use
> > the directive in EXACTLY the same way, we will still need to document them
> > separately and make separate entires in directives.html.
> 
> Well, we have tried to make sure that whenever a directive is used by
> different MPMs, that it is always implemented the same way on each
> platform.  

OK.  I don't really care about the implimentation at this point, but if we
can say "All MPMs which use a common directive name will have the same
syntax, defaults, and basic operation of that directive", then we can save
a lot of work by throwing many of the directives in a
htdocs/mod/mpm_common.html file and referencing them from the other
mpm_????.html docs.

Can we make this a policy?

Joshua.

Re: MPM documentation

[rb...@covalent.net]

> > > 4. I believe that there are going to be many different MPMs using the
> > > same directive names.  Unless we can guarantee that all the MPMs will use
> > > the directive in EXACTLY the same way, we will still need to document them
> > > separately and make separate entires in directives.html.
> > 
> > Well, we have tried to make sure that whenever a directive is used by
> > different MPMs, that it is always implemented the same way on each
> > platform.  
> 
> OK.  I don't really care about the implimentation at this point, but if we
> can say "All MPMs which use a common directive name will have the same
> syntax, defaults, and basic operation of that directive", then we can save
> a lot of work by throwing many of the directives in a
> htdocs/mod/mpm_common.html file and referencing them from the other
> mpm_????.html docs.
> 
> Can we make this a policy?

It is currently a policy, it just isn't documented.  So, now it's a
documented policy.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: MPM documentation

[rb...@covalent.net]

> > > 4. I believe that there are going to be many different MPMs using the
> > > same directive names.  Unless we can guarantee that all the MPMs will use
> > > the directive in EXACTLY the same way, we will still need to document them
> > > separately and make separate entires in directives.html.
> > 
> > Well, we have tried to make sure that whenever a directive is used by
> > different MPMs, that it is always implemented the same way on each
> > platform.  
> 
> OK.  I don't really care about the implimentation at this point, but if we
> can say "All MPMs which use a common directive name will have the same
> syntax, defaults, and basic operation of that directive", then we can save
> a lot of work by throwing many of the directives in a
> htdocs/mod/mpm_common.html file and referencing them from the other
> mpm_????.html docs.
> 
> Can we make this a policy?

It is currently a policy, it just isn't documented.  So, now it's a
documented policy.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------