Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 24533 invoked by uid 500); 12 Apr 2001 15:51:13 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 24514 invoked from network); 12 Apr 2001 15:51:13 -0000 Errors-To: Message-ID: <021101c0c368$435c6e40$94c0b0d0@roweclan.net> Reply-To: "William A. Rowe, Jr." From: "William A. Rowe, Jr." To: References: Subject: Re: [PATCH] mpm_query_2 Date: Thu, 12 Apr 2001 10:48:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N From: Sent: Thursday, April 12, 2001 10:37 AM > On Thu, 12 Apr 2001, Harrie Hazewinkel wrote: > > > rbb@covalent.net 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. > > 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. or ap_mpm_something, since that appears to be the convention. Yes, I'll +1 adding Harrie's patch (sans string) and a string getname function as you've suggested. Unless we have a massive list of other 'string' queries, which I doubt. This makes both functions more typesafe and simpler.