----- 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-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
