Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4F852843.6090007@redhat.com>
References: <4F852843.6090007@redhat.com>
Date: Mon, 7 May 2012 21:26:40 -0700
Message-ID: 
 <CAHrynWD1n5jNLLOXRqWc-mBUc0TAF=vbEDAVuPjzaZ1vDSehjg@mail.gmail.com>
Subject: Re: mod_perl and httpd-2.4
From: Fred Moyer <fred@redhotpenguin.com>
To: =?UTF-8?Q?Jan_Kalu=C5=BEa?= <jkaluza@redhat.com>
Cc: dev@perl.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 11:44 PM, Jan Kalu=C5=BEa <jkaluza@redhat.com> wrot=
e:
> I've talked with Torsten about the mod_perl and httpd-2.4 compatibility a=
nd
> he advised me to start discussion about this problem.
>
> Attached patch against httpd24 branch fixes the compilation with httpd-2.=
4.
> I was not able to generate xs using "make source_scan", so I've changed t=
hem
> manually. Should source_scan.pl work...?

What changes to source_scan.pl did you have to make?

I've gotten httpd 2.4 to compile successfully, and I think this patch
will work in terms of the api changes, but it needs to provide the
appropriate method depending on the httpd minor version, remote_ip for
2.0, 2.2 and client_ip for 2.4. I'm not sure where that happens yet in
the codebase - maybe FunctionTable.pm?

I would favor the compatibility layer approach personally. I have some
code on CPAN that uses remote_ip, so I don't really want to go change
that to support 2.4 just yet.


>
> Except the source_scan.pl issue, there is one issue which has to be
> addressed too.
>
> conn_rec->remote_ip and conn_rec->remote_addr have been removed and repla=
ced
> by request_rec->useragent_ip, request_rec->useragent_addr and
> conn_rec->client_ip, conn_rec->client_addr. See [1] to read about the
> differences between them.
>
> There are two ways how to address this issue:
>
> 1. Break the compatibility with older mod_perl versions. The advantage is
> that mod_perl will stay consistent with httpd and mod_perl developers wou=
ld
> not have to maintain the compatibility layer.
>
> The disadvantage is that if there are projects using mod_perl and
> remote_ip/remote_addr, they would have to be fixed too. However, it's the
> very same situation like with httpd-2.4, where all the modules using
> remote_ip/remote_addr have to be fixed too.
>
> 2. Introduce the compatibility layer. I'm not Perl expert, but I think wi=
th
> the way how mod_perl is built currently it's not doable out-of-box (I can=
 be
> wrong of course).
>
> Interesting thing is also that most modules I've ported to httpd-2.4 use
> remote_ip/remote_addr in the meaning of useragent_ip/useragent_addr. In
> http-2.4 these two pairs are members of different structs (conn_rec and
> request_rec). I think I can't imagine how would we map conn_rec->remote_i=
p
> to request_rec->useragent_ip...
>
>
> Personally I would vote for the number 1 and bumping mod_perl version.
>
> I'm not Perl developer, I just co-maintain mod_perl in Fedora and in the
> development version httpd has been updated to 2.4, so mod_perl is not
> building there anymore.
>
> Regards,
> Jan Kaluza
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org