perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Moyer <f...@redhotpenguin.com>
Subject 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
Date Fri, 22 May 2009 16:35:10 GMT
Forwarding sent mail - thought I was replying to dev@perl but it was dev@httpd


---------- Forwarded message ----------
From: Fred Moyer <fred@redhotpenguin.com>
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@gmail.com>
Cc: dev@httpd.apache.org


On Thu, May 21, 2009 at 12:25 PM, Jeff Trawick <trawick@gmail.com> wrote:
> On Thu, May 21, 2009 at 3:08 PM, William A. Rowe, Jr. <wrowe@rowe-clan.net>
> 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@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message