----- Original Message ----- > On Sun, Jun 23, 2013 at 1:52 PM, Niko Tyni <nt...@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-unsubscr...@perl.apache.org > For additional commands, e-mail: dev-h...@perl.apache.org > > Regards, Jan Kaluza --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
