You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2010/04/01 00:35:01 UTC
Re: svn commit: r929663 - /httpd/httpd/trunk/include/http_config.h
On 3/31/2010 4:46 PM, Jeff Trawick wrote:
>
> Why not just change the signature of ap_process_resource_config() ?
> What is the anticipated use of these functions? (IOW, how much pain
> does it introduce?)
I see an advantage of two API's if we revert ap_process_resource_config()
to what it was supposed to be, a processor for a single config file. Then
ap_process_resource_config_ex() is really ap_process_resource_configs_matching()
or something like that.
Re: svn commit: r929663 - /httpd/httpd/trunk/include/http_config.h
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 2, 2010, at 8:39 AM, Jeff Trawick wrote:
> On Wed, Mar 31, 2010 at 6:35 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> On 3/31/2010 4:46 PM, Jeff Trawick wrote:
>>>
>>> Why not just change the signature of ap_process_resource_config() ?
>>> What is the anticipated use of these functions? (IOW, how much pain
>>> does it introduce?)
>>
>> I see an advantage of two API's if we revert ap_process_resource_config()
>> to what it was supposed to be, a processor for a single config file. Then
>> ap_process_resource_config_ex() is really ap_process_resource_configs_matching()
>> or something like that.
>
> That is a very natural division.
>
+1
Re: svn commit: r929663 - /httpd/httpd/trunk/include/http_config.h
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Mar 31, 2010 at 6:35 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 3/31/2010 4:46 PM, Jeff Trawick wrote:
>>
>> Why not just change the signature of ap_process_resource_config() ?
>> What is the anticipated use of these functions? (IOW, how much pain
>> does it introduce?)
>
> I see an advantage of two API's if we revert ap_process_resource_config()
> to what it was supposed to be, a processor for a single config file. Then
> ap_process_resource_config_ex() is really ap_process_resource_configs_matching()
> or something like that.
That is a very natural division.