> may be we should be more flexible right away and use the same approach > Apache uses, i.e. have each custom module a say for its insertion > priority. So we could add mod_perl as middle module and give other > modules an opportunity to load themselves before (first/very_first or > after (last/very_last) mod_perl or some other module. It really > shouldn't be mod_perl centric as more and more non-perl projects start > to use A-T.
well, I think this is kinda a mod_perl problem, since we're only talking about TestConfigurePerl and it's special treatment of mod_perl. if you use TestConfig or TestConfigPHP then the modules are just inherited from httpd.conf (mod_perl included) in the order in which they appear there, which is typically what the user wants. in general, I think it is atypical that one apache module depends on another module being loaded before it itself can load. that is, in a LoadModule sense - sure, lots of things depend on mod_perl, but they use PerlModule not LoadModule. embperl seems to be the exception to this. axkit would be the only other I could think of but I just verified that it uses PerlModule as well. > So instead of printing the modules right away they could be > assembled into an array which will be then resorted the way the user > wants. e.g.: > > add_foo(...., before => "mod_perl.c"); > add_foo(...., after => qw[mod_perl.c mod_proxy.c]); > > or have those before/after/last/first/etc encoded in the API instead... well, I think that for the most part inheriting order from httpd.conf is sufficient, at least for the moment, but we can always create a larger API later when time allows. for the moment, though, I think I'm happy to make an exception for embperl within TestConfigPerl. at least until somebody complains :) --Geoff
