fred at redhotpenguin
May 22, 2009, 9:35 AM
Post #1 of 1
(945 views)
Permalink
|
|
Fwd: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
|
|
Forwarding sent mail - thought I was replying to dev [at] per but it was dev [at] http
---------- Forwarded message ----------
From: Fred Moyer <fred [at] redhotpenguin>
Date: Fri, May 22, 2009 at 9:33 AM
Subject: Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x:
CHANGES STATUS include/http_core.h modules/filters/mod_include.c
server/config.c server/core.c
To: Jeff Trawick <trawick [at] gmail>
Cc: dev [at] httpd
On Thu, May 21, 2009 at 12:25 PM, Jeff Trawick <trawick [at] gmail> wrote:
> On Thu, May 21, 2009 at 3:08 PM, William A. Rowe, Jr. <wrowe [at] rowe-clan>
> wrote:
>> Jeff Trawick wrote:
>> > Does somebody else care to share their opinion on this? Which of these
>> > are okay?
>> > - existing mod_perl releases (and potentially other third-party modules)
>> > won't compile with 2.2.12
>> CORE_PRIVATE may be broken from release to release, it's a necessary
>> concession to prevent utter stagnation :(
>
> The bits are not CORE_PRIVATE.
>
> You can find sample Perl code on the web that even tests these bits, though
> it isn't clear to me if that is a normal practice when using the
> Perl/mod_include interface.
Jeff would you be so kind as to post a link to this sample code so
that those of us here without a clue (myself) can understand the issue
in depth?
>>
>>
>> I believe it was a mistake that this particular symbol/this particular
>> directive is not a part of the mod_includes internals :(
>
> Perhaps, though mod_include does have a plug-in interface and we have this
> non-internal-detail-sounding function called ap_allow_options(). The
> include option variants could be interesting to such a plug-in.
>
>
>>
>>
>> So given we have a .23 mmn bump, perhaps document this in that section.
>> But the actual behavior of this flag changes significantly and I can't
>> see how to properly maintain mod_perl, deep internal compatibility.
>>
>
> The requirement is to fix combinations of option specifications in the main
> conf file and .htaccess. There's nothing incompatible with mod_perl there.
> We just can't change the meaning of existing bits.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl
|
