Mailing List Archive

----- Original Message -----
> Fred Moyer <fred@redhotpenguin.com>:
>
> > > What else? Time for 2.4 httpd?
>
> Debian is also moving to Apache 2.4 and we've been working on getting
> mod_perl2 to cope. We're currently using the httpd24 branch as a base
> (thanks for your work, Jan!), merged with the 2.0.8 release. We found
> a few issues that I intend to post as separate patches / reports soonish,
> but we've generally got it working now.

Great news! Fedora is using httpd24 branch and I know some people using it
in their projects with httpd-2.4 without any problems.

I'm more than happy to apply patches to the httpd24 branch if you don't have
commit access there. I will try to re-merge current trunk with httpd24 branch
soon - today or on Monday (I have done that some months ago for last time).

> On Fri, Apr 19, 2013 at 02:22:25AM -0400, Jan Kaluza wrote:
>
> > I think we have to create new mod_perl row for httpd24 or change the build
> > process.
>
> FWIW I'd be willing to help here too (as time permits), but I'm not
> really familiar with the build process. Opinions and advice from more
> experienced mod_perl developers would be welcome.

I think what we are lacking here right now is some sort of decision what
to do next. I can't decide which way should the development go, I don't
have permissions (politically, not technically) to commit to trunk and
so on.

> Selectively quoting the options you listed:
>
> > a) have two branches - trunk and httpd24 (analogy to httpd-trunk and
> > httpd-2.4).
>
> I think this is clearly not optimal in the long term, but if it is how
> things are going to be, maybe SVN merges would help to avoid committing
> everything twice.
>
> At the moment httpd24 is lagging behind trunk. There seems to be a need
> for making sure they stay synchronised.

This is temporary state and it was supposed to be like that only before
someone from core mod_perl developers decides how to continue with the
development... As I said before in this email, I will re-merge httpd24
branch and if we decide to choose this way, I think I would be able to
merge it regularly.

> Would there be separate releases for 2.0.9 and 2.0.9-httpd24 ?

I think we will have to support both for some time, so yes. The problem
could be that some aspects of -httpd24's API differs from httpd22's
2.0.9. Technically this means that we would be providing two different
versions, so maybe we could even number them differently, like 2.0.9 and 3.0.9?
Both would share the same base code, but the latter one would be tweaked for
httpd24.

I'm not sure it's good idea, it was just something I had in my mind.

> > b) have just trunk for both httpd24 and httpd22 code
> [...]
> > I don't know XS well, but if you think it's easy enough to change build to
> > use different
> > xs directory (or its subset) for 2.4 and different for 2.2, then I think
> > this is way to go.
>
> As I understand it, this has the drawback that a developer changing an
> xs map needs to have access to both 2.2 and 2.4 to run 'xs_generate'
> for both. But I guess they'd have to have that anyway for testing.

Hm, yes, they would need to generate for both versions, which could be
tricky, because you can't have both httpd versions installed at the same
time.

On the otherside, I'm not sure there will be some case when
xs has to be regenerated for both 2.2 and 2.4. All the important variables are
already wrapped for 2.2 and since I read this list (1.5 years), I haven't
seen such activity. So I think this is not so problematic. Developers
working with httpd-2.4 will likely change only httpd-2.4 related xs
files without touching httpd-2.2 versions.

> How was this handled for the Apache 2.0 -> 2.2 changes? Are there just
> more API differences in 2.4?

That's question for someone who was here when this migration happened...

> > c) merge just httpd24 .c/.h changes to trunk and let the users/devs to run
> > make xs_generate
> > themselves and try to fix the /usr/include/ parser to be more reliable.
>
> For the purposes of Debian alone, I think c) would be adequate (we
> probably could and should make sure xs_generate works there), but
> I agree b) is generally better for end users.

Right, in Fedora I've been doing that for some time, but when I committed
my patchset to httpd24 branch, I have found out this is not good for end
users, because parsing system headers tends to be error-prone. But if you
build in stable environment, it's not problem to tweak the parsing to ignore
right headers and make this way working. It's just not the way of building
I would support globally.

> --
> Niko Tyni ntyni@debian.org
>

Regards,
Jan Kaluza

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

On Fri, Jun 21, 2013 at 05:18:24AM -0400, Jan Kaluza wrote:

> I'm more than happy to apply patches to the httpd24 branch if you don't have
> commit access there. I will try to re-merge current trunk with httpd24 branch
> soon - today or on Monday (I have done that some months ago for last time).

Great, thanks! I've gone over my notes now and sent here the patches
I had queued up. Hope the patch dump ended up in the right place and
didn't annoy anybody on the list.

> I think what we are lacking here right now is some sort of decision what
> to do next. I can't decide which way should the development go, I don't
> have permissions (politically, not technically) to commit to trunk and
> so on.

OK, I'll postpone the rest of the discussion until somebody with
more authority joins in.

> > At the moment httpd24 is lagging behind trunk. There seems to be a need
> > for making sure they stay synchronised.
>
> This is temporary state and it was supposed to be like that only before
> someone from core mod_perl developers decides how to continue with the
> development... As I said before in this email, I will re-merge httpd24
> branch and if we decide to choose this way, I think I would be able to
> merge it regularly.

Thanks again!
--
Niko Tyni ntyni@debian.org

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

On 06/23/2013 10:52 PM, Niko Tyni wrote:
>>> At the moment httpd24 is lagging behind trunk. There seems to be a need
>>> for making sure they stay synchronised.
>>
>> This is temporary state and it was supposed to be like that only before
>> someone from core mod_perl developers decides how to continue with the
>> development... As I said before in this email, I will re-merge httpd24
>> branch and if we decide to choose this way, I think I would be able to
>> merge it regularly.
>
> Thanks again!
>

Merged in http://svn.apache.org/r1496004 . I will try to merge with
trunk more frequently now.

Regards,
Jan Kaluza


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

On Sun, Jun 23, 2013 at 1:52 PM, Niko Tyni <ntyni@debian.org> wrote:
> On Fri, Jun 21, 2013 at 05:18:24AM -0400, Jan Kaluza wrote:

>> I think what we are lacking here right now is some sort of decision what
>> to do next. I can't decide which way should the development go, I don't
>> have permissions (politically, not technically) to commit to trunk and
>> so on.
>
> OK, I'll postpone the rest of the discussion until somebody with
> more authority joins in.

So what are the implications of merging these to trunk? I've been
following the thread somewhat. Will this be backward compatible with
2.0.x?

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

----- Original Message -----
> On Sun, Jun 23, 2013 at 1:52 PM, Niko Tyni <ntyni@debian.org> wrote:
> > On Fri, Jun 21, 2013 at 05:18:24AM -0400, Jan Kaluza wrote:
>
> >> I think what we are lacking here right now is some sort of decision what
> >> to do next. I can't decide which way should the development go, I don't
> >> have permissions (politically, not technically) to commit to trunk and
> >> so on.
> >
> > OK, I'll postpone the rest of the discussion until somebody with
> > more authority joins in.
>
> So what are the implications of merging these to trunk? I've been
> following the thread somewhat.

(Note that I have already mentioned my ideas about future development
in this thread [1])

We can't merge it with trunk right now.
The problem is that for httpd24, we have to regenerate the "xs" directory
(already done in httpd24 branch) and tweak for example "xs/maps/*" for
new httpd24 API.

Since there can't be conditionals in those files currently, it's impossible
to have the same xs/* files for both httpd versions. The solution for this
could be another "xs24" directory with httpd-2.4 xs files, or improving all
the generators in lib/ModPerl to support something like #ifdef in those files.

I think the separate "xs24" directory is easier to implement definitely.
Maybe it doesn't have to be whole xs directory, but just xs/maps and
xs/tables subdirectries. Someone would have to check that :).

I haven't tried to compile httpd24 branch with httpd-2.2 and I presume it
won't work, but I will fix it if we decide to go this way and make it
compilable even with httpd-2.2 (using #ifdefs in C code).

> Will this be backward compatible with 2.0.x?

Partly. It depends on the httpd API you rely on. Lot of things changed
[1] between 2.2 and 2.4 and that is reflected also in httpd24 branch code.
If you check the revision log for the modperl tests in the httpd24 branch,
you can get better idea about changes.

I think it's not possible to keep backward compatibility with 2.0.x. Some
API changes (like the auth API or just simple remote_ip/remote_addr struct
fields) are just so different that we can't make them backward compatible.

[1] http://mail-archives.apache.org/mod_mbox/perl-dev/201304.mbox/%3C1432642653.2888638.1366352545568.JavaMail.root%40redhat.com%3E
[2] http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html

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

Regards,
Jan Kaluza

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

On 24/06/13 19:36, Jan Kaluza wrote:
> Since there can't be conditionals in those files currently, it's impossible
> to have the same xs/* files for both httpd versions. The solution for this
> could be another "xs24" directory with httpd-2.4 xs files, or improving all
> the generators in lib/ModPerl to support something like #ifdef in those files.

You can actually do something similar to:

#_if_ $^O !~ /mswin/i
~apr_os_sock_get
#_else_
-apr_os_sock_get
#_end_

It's implemented in lib/ModPerl/MapUtil.pm in ModPerl::MapBase::readline.

Here is the syntax:

"if"

# _if_ CONDITION
...
# _elsif_ CONDITION
...
# _else_
...
# _end_

"unless":

# _unless_ CONDITION
...
# _elsif_ CONDITION
...
# _else_
...
# _end_

nested conditionals:

# _if_ CONDITION
...
# _if_ CONDITION
...
# _end_
...
# _end_

"eval"

# _eval_ CODE

like in

# _if_ $^O =~ /mswin/i
# _eval_ warn "Running on Windows"
# _end_

CODE and CONDITION is just perl code. But it must be one line. If you
require multi-line code blocks we can implement some kind of
continuation lines. But I think this should not be necessary.

Torsten

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

On 24/06/13 19:36, Jan Kaluza wrote:
> I think the separate "xs24" directory is easier to implement definitely.
> Maybe it doesn't have to be whole xs directory, but just xs/maps and
> xs/tables subdirectries. Someone would have to check that :).

I think I don't like the idea of having separate directories because
later on if you want to change something you always have to look out to
change it in all the places. On the other hand, keeping one set of maps
may also lead to very complex code with multiple instances of the same
thing. So, I'm not quite sure which way to go.

>> > Will this be backward compatible with 2.0.x?
> Partly. It depends on the httpd API you rely on. Lot of things changed
> [1] between 2.2 and 2.4 and that is reflected also in httpd24 branch code.
> If you check the revision log for the modperl tests in the httpd24 branch,
> you can get better idea about changes.
>
> I think it's not possible to keep backward compatibility with 2.0.x. Some
> API changes (like the auth API or just simple remote_ip/remote_addr struct
> fields) are just so different that we can't make them backward compatible.

Completely true. The problem with such a compatibility layer is that it
raises false hopes that your software works with the new code if you
just change a tiny bit.

Thanks, Jan, Niko, for all the work.

Jan, why do you think you don't have permission to commit to trunk? I
wouldn't say that is true.

Torsten

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

----- Original Message -----
> On 24/06/13 19:36, Jan Kaluza wrote:
> > I think the separate "xs24" directory is easier to implement definitely.
> > Maybe it doesn't have to be whole xs directory, but just xs/maps and
> > xs/tables subdirectries. Someone would have to check that :).
>
> I think I don't like the idea of having separate directories because
> later on if you want to change something you always have to look out to
> change it in all the places. On the other hand, keeping one set of maps
> may also lead to very complex code with multiple instances of the same
> thing. So, I'm not quite sure which way to go.

I don't have the code here right now, but I think there's also another
problem not related to xs/maps and xs/tables directories. We probably have
to split "make source_scan" and "make xs_generate" output into special
directories according to httpd version anyway.

As I said in my earlier email, it's not good to force users to run source_scan,
because it's not reliable command. We should provide pregenerated xs wrapping
for 2.4 the same was as we do already for 2.2. But if we will do that, we must
logically save it into different directory.

It's still better than previous aproach, because we have single source code
(single xs/maps, xs/tables, ..., directories), but we still have to split
the output generated from these source codes.

> >> > Will this be backward compatible with 2.0.x?
> > Partly. It depends on the httpd API you rely on. Lot of things changed
> > [1] between 2.2 and 2.4 and that is reflected also in httpd24 branch code.
> > If you check the revision log for the modperl tests in the httpd24 branch,
> > you can get better idea about changes.
> >
> > I think it's not possible to keep backward compatibility with 2.0.x. Some
> > API changes (like the auth API or just simple remote_ip/remote_addr struct
> > fields) are just so different that we can't make them backward compatible.
>
> Completely true. The problem with such a compatibility layer is that it
> raises false hopes that your software works with the new code if you
> just change a tiny bit.
>
> Thanks, Jan, Niko, for all the work.
>
> Jan, why do you think you don't have permission to commit to trunk? I
> wouldn't say that is true.

Well, I have originally asked for access to commit to httpd24 branch and
I thought my commit access was granted with this condition. I actually
don't know if I can commit to trunk or for example to Apache-Test.
That's why Joe committed the Apache-Test parts of Niko's patches.

Anyway, I will work in httpd24 branch for now, there's no need to merge
it with trunk until we decide what to do next and until we fix
the building process to reflect this decision.

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

Regards,
Jan Kaluza

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

On Tue, Jun 25, 2013 at 8:09 AM, Torsten Förtsch
<torsten.foertsch@gmx.net> wrote:
> On 24/06/13 19:36, Jan Kaluza wrote:
>> I think the separate "xs24" directory is easier to implement definitely.
>> Maybe it doesn't have to be whole xs directory, but just xs/maps and
>> xs/tables subdirectries. Someone would have to check that :).
>
> I think I don't like the idea of having separate directories because
> later on if you want to change something you always have to look out to
> change it in all the places. On the other hand, keeping one set of maps
> may also lead to very complex code with multiple instances of the same
> thing. So, I'm not quite sure which way to go.

I'd be in favor of more complex code here rather than separate
directories. Maybe there's more head scratching, but probably less
support issues. And as older API's become deprecated, our code could
become simpler.

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