Return-Path: Delivered-To: apmail-perl-modperl-cvs-archive@www.apache.org Received: (qmail 31727 invoked from network); 17 Nov 2003 23:00:35 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 17 Nov 2003 23:00:35 -0000 Received: (qmail 18407 invoked by uid 500); 17 Nov 2003 23:00:22 -0000 Delivered-To: apmail-perl-modperl-cvs-archive@perl.apache.org Received: (qmail 18395 invoked by uid 500); 17 Nov 2003 23:00:22 -0000 Mailing-List: contact modperl-cvs-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@perl.apache.org Delivered-To: mailing list modperl-cvs@perl.apache.org Received: (qmail 18382 invoked by uid 500); 17 Nov 2003 23:00:21 -0000 Delivered-To: apmail-modperl-2.0-cvs@apache.org Date: 17 Nov 2003 23:00:34 -0000 Message-ID: <20031117230034.31715.qmail@minotaur.apache.org> From: stas@apache.org To: modperl-2.0-cvs@apache.org Subject: cvs commit: modperl-2.0/todo bugs_apr_ext bugs_build bugs_mp bugs_registry release features_maybe features_missing features_new design_notes X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N stas 2003/11/17 15:00:34 Added: todo bugs_apr_ext bugs_build bugs_mp bugs_registry release features_maybe features_missing features_new design_notes Log: bugs/issues reorg, plan 2.0 release. work in progress [worked out by Geoff, Philippe, Stas in Vegas] Revision Changes Path 1.1 modperl-2.0/todo/bugs_apr_ext Index: bugs_apr_ext =================================================================== ######################################## # external (non-mod_perl) APR:: issues # ######################################## * As mike chamberlain told me over irc, apr-ext/perlio was faling for him because of the modperl_perl_gensym not being resolved in APR/PerlIO.so. I didn't see that error since on linux by default symbols resolution is lazy and since that part of the api wasn't tested I did see the problem. On MacOSX the loading is RTLD_NOW (non-lazy) so it detects any missing symbols problems immediately. Luckily DynaLoader allows us to force the non-lazy mode by setting an env var: PERL_DL_NONLAZY=1. We need to force this env variable on when building with MP_MAINTAINER=1. I suppose that it should be added to the autogenerated t/TEST and t/SMOKE. and to t/conf/modperl_extra.pl ($ENV{PERL_DL_NONLAZY}=1) so it affects the server-side as well as the client-side (normally env var aren't propogated to the server). * APR::Table now depends on modperl_hash_tie, so it can't be used outside mod_perl. should probably abstract this function into a new utils.c object that can be linked by APR.so. Status: see the next item * APR::PerlIO needs an equivalent of modperl_perl_gensym Status: we need to abstract those function into a separate object, which can be linked by APR.so. However I think we should probably provide a static build and after that see how to do the linking right. Otherwise we may have collisions with statically linked symbols and the dynamic ones. APR::Pool relies on interpreter management functions and therefore can't be used outside mod_perl. Status: 1.1 modperl-2.0/todo/bugs_build Index: bugs_build =================================================================== ####################### # Build/Startup Issue # ####################### OS Ver Mod Comments ---------------------------------------------------------------------- OpenBSD 2.9 DSO Builds but won't start, with segfaults in the Perl lexer. I wasn't even able to start mp1-dso with the customly built perl (tried 5.6.1 .. 5.9.0) -- the segfault is again in lexer. It seems that the standard OpenBSD perl package has been heavily patched, when the core system perl 5.6.0 package was built, since I can run 'make test' on mp1-dso, but not with a customly built 5.6.0 with the same options. Since 2.9 is no longer supported by OpenBSD, there is no 5.6.1 or higher to try, so at this moment we simply give up on 2.9. We think that the static mp2 build should work just fine (once it's available). AIX 3.3 DSO Works with -berok to ignore linking errors (symbol resolution). Should replace -berok with a proper symbol resolution at linking time, but I had not much success with using this approach (dlopen fails). FreeBSD ?? DSO Works with non-threaded perl (4.8-RELEASE and 5.1-RELEASE) http://marc.theaimsgroup.com/?l=apache-modperl&m=106399870822612&w=2 It doesn't work with threaded perl/worker mpm, seemingly because of the problems with threads on FreeBSD (not sure what version). * we should stop generating xs/apache_*, at least for a reason that it's incomplete and will be never complete as we don't keep up with changes with ap_/apr_ namespace. Also we don't have the logic to handle cases where functions aren't available on certain platforms. Importing these unavailable functions may cause loading problems on some platforms (aix?). If developers need to import symbols from ap_/apr_ namespace they should use .exp files installed by httpd/apr/aprutil. * gcc 3.3 (from cvs 2003-07-28) supports a new option: -Wdeclaration-after-statement, which we need to enable in the maintainer mode, to catch any declarations after statements, since by default gcc doesn't complain about them. Probably need to wait till gcc-3.3.2 and enable it then. http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?r1=2.639&r2=2.640&f=h * Testing: Need to put Philippe's smoking test into the core -- shouldn't forget to test with perlio enabled and disabled * mp2bug -- add the output of 'ldd httpd' to the report 1.1 modperl-2.0/todo/bugs_mp Index: bugs_mp =================================================================== ################# # mod_perl bugs # ################# * PassEnv/SetEnv propogation in section http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/%5BMP2_BUG%5D_PerlPassEnv_issues_P70500/ * we have a dependency check problem when xs/*/*.h use code from xs/modperl_xs*.h, when the latter change 'make' won't rebuild the dependant files * most of the xs wrappers print no "Usage: " when wrong args/wrong number of args are passed, would be nice to add the usage message whenever incorrect arguments error is logged. e.g., when APR::URI->parse() gets the wrong first arg (non-pool) it prints: p is not of type APR::Pool at ... whereas it's not so obvious that the function expected the pool object, neither it specifies which ("arg number") of the arguments is wrong. possible solution: add a new field to the map files, which will be used as a usage message whenever an argument error occurs. * 'SetHandler modperl' doesn't reset $|, so if anything turns it on anywhere, it's going to stay that way. Meaning excessive flushing probably causing a performance hit. I've tried to add the code to reset it, but this requires getting a perl interpreter at the early stage and it breaks several filter tests, which has relied before on the coincidence that both the response handler and the filter were run by the same interpreter (in particular this breaks the code where push_handlers() uses a string as a handler, rather a CODE reference, see t/filter/TestFilter/both_str_rec_add.pm, to reproduce the problem, simply s/modperl/perl-script/) * $r->rflush doesn't work. see: http://marc.theaimsgroup.com/?l=apache-modperl&m=103847990813285&w=2 I also see a weird behavior where it does sends FLUSH buckets but they all seem to fall through the data, thus not really flushing anything. this can be easily reproduced with MyApache::FilterSnoop. * Apache::Log compat issues: Apache->warn, Apache::warn, Apache::Server->warn and Apache->Apache::Server->log_error are all doing: s = modperl_global_get_server_rec(); and this function is thread safe only during the startup. possible solutions: 1) enforce that these functions are used only at the server startup 2) require +GlobalRequest, which gives us r->server, now thread safe (though slow). 3) drop them all from the API and move to compat. [remember that Apache::warn is needed for registry scripts to override warn()] For Apache::warn and registry, the solution is to supply GLOBAL::CORE::warn for the current request and get $r inside of it and] Report: Message-ID: Status: Doug, contemplating * see if we can avoid touching environ[] until a fork() from Perl happens 1.1 modperl-2.0/todo/bugs_registry Index: bugs_registry =================================================================== ########################## # Registry specific bugs # ########################## * protect registry classes from bad scripts which try to assassinate $r Report: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106153785129782&w=2 Status: (stas) i'm not sure whether we really need this feature, since it's the first time in the last 6 years we had a problem with bad user code of this kind. let's keep it in the patches until we have a real need for it. Priority: very low 1.1 modperl-2.0/todo/release Index: release =================================================================== ################################################## # Things to be resolved for mod_perl 2.0 release # ################################################## * static build - if we make it working on OpenBSD, AIX and FreeBSD, then it's not important to fix the DSO issues, otherwise make the DSO issues a release issue. * perl Makefile.PL PREFIX=/foo/bar works fine, however Makefile.PL'll still refuse to build unless MP_INST_APACHE2=1 is passed. It should refuse to do so only if it finds mod_perl 1.0 installed under that PREFIX, which can be a tricky check, since the exact logic to figure out the paths is deep inside EU::MM. Probably it's better to run 'File::Find' and search for 'mod_perl.pm' under PREFIX, if found check its version and assert only if it's 1.xx * META.yml. Generate META.yml (make dist does that), add Apache-Test as a private resource, so it won't be attempted to be indexed by PAUSE, add NO_META=>1 to WriteMakefile() which tells EU::MM not to overwrite META.yml. * sections: A few issues with sections: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106074969831522&w=2 * Recursive sections: http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/%5BMP2_-_BUG_%5D_Issue_handing_Apache_config._error_messages_P70501/ and http://mathforum.org/epigone/modperl/dartrimpcil * Fixing Apache->warn("foo") Report: http://mathforum.org/epigone/modperl-dev/noxtramcay/3D11A4E5.6010202@stason.org Thread: http://mathforum.org/epigone/modperl-dev/noxtramcay Status: pending Apache::Log compat issues, this and other methods might be dropped. * per-server cleanups core dump or are otherwise ineffective Apache->server->process->pconf->cleanup_register(sub { ... }); Report: geoff * Looks like there is an issue with filter configuration, I've noticed that: PerlInputFilterHandler MyApache::InputFilterGET2HEAD silently ignores the filter, whereas: ^^^^^^^^^^^^^^^^ PerlInputFilterHandler +MyApache::InputFilterGET2HEAD calls the filter. figure out: - why the loading doesn't happen - why the error doesn't happen (probably both connected) * Currently modperl_filter_add_{connection|request} check the filter handler function attrs before accepting the filter. If the module wasn't preloaded the check fails and filter handler is skipped. We could have this issue documented (which is OK, but might raise too many questions), but we could also always preload the filter handlers. To test see TestFilter::input_msg * child processes never run END blocks. a good example is Apache::TestUtil, which doesn't cleanup files and dirs it has created, because the END block is not run. also: see the next item * ModPerl::Registry END {} block woes , described in details at the forwarded message from Jim Schueler http://marc.theaimsgroup.com/?l=apache-modperl&m=103720834717981&w=2 the whole thread is here: http://marc.theaimsgroup.com/?t=103713532800003&r=1&w=2 * we still have a problem with mod_perl starting from a vhost. consider the following config: PerlSwitches -I/foo/bar PerlLoadModule TestDirective::perlloadmodule6 ... The value set by PerlSwitches in the main server is ignored, because it's not seen by mod_perl starting from vhost. overall, currently the early startup in vhost is a bunch of ugly workaround, which I've added everytime I came up with a config that wasn't working. Need to come up with a better design decisions. once this is fixed. I want the perlloadmodule6 to be loaded before all other perlloadmodule configs, because it tests an important segfault when perlloadmodule happens to start mod_perl from within a vhost. but because PerlSwitches from other tests are ignored, it can't trigger the mod_perl startup in the test suite. - anonymous handler (for push_handlers, add_input_filter, etc), see modperl_mgv.c: modperl_mgv_name_from_sv - PerlModule, PerlRequire, Perl{Set,Add}Var in .htaccess is missing Owner: geoff - cgi emulation: %ENV management: - %ENV is currently only saved/restored for the perl-script handler, i.e. changes to %ENV outside of a perl-script handler are not cleared. of course, "clean" modules would use local() to modify %ENV, but there should be an option to save/restore globals outside of the perl-script handler STATUS: do the cleanup for all handlers, but provide a new config option so users can disable it if they know what they are doing. * Apache::SizeLimit and Apache::Resource * It'd be nice to have PAUSE and the clients support packages with several versions, like mod_perl 1.0 and mod_perl 2.0, since once we release it any dependency on mod_perl will be resolved as mod_perl 2.0, when mod_perl 1.0 may be required instead. 1.1 modperl-2.0/todo/features_maybe Index: features_maybe =================================================================== ######################### # Nice to have features # ######################### * PerlPreConnectionHandler is implemented, but the 'void *csd' arg in the callback is ignored. will require a modification of modperl_callback_run_handlers to pass yet another optional argument. Status: most likely nobody will ever want to use this option, so don't waste time working on it. 1.1 modperl-2.0/todo/features_missing Index: features_missing =================================================================== ######################## # mp1 missing features # ######################## * Apache::PerlSections->dump It does exist, but it's a completely internal function, not dumping existing configuration as it used to be in 1.x. (needed by Apache::Status, for instance). Need to be implemented and the existing dump method must be moved out of the way * directive handlers are supported but need some work for 1.x compat - Apache::ModuleConfig->get needs a compat method mapping to Apache::Module->get_config - Apache::CmdParms::{GETC,getline} needs compat mapping, similar to what Apache::Directive->as_string does, but one char or line at a time * Apache::PerlSections missing features for backwards compatibility: - $Apache::ReadConfig::DocumentRoot - Apache::PerlSections->store(filename) Report: Philippe M. Chiasson Status: Philippe M. Chiasson is working on it * PerlOpCodeMask (experimental in 1.xx) * die 404 (consider deprecating it) * mod_perl.pm::import - Apache::test: tobe a compat stub around new test framework - Apache::src: tobe a compat stub around new build framework 1.1 modperl-2.0/todo/features_new Index: features_new =================================================================== ####################### # New features in mp2 # ####################### * filters tie handle/perlio interface both input/output filters should provide a tiehandle and/or perlio interface. Perl tiehandle methods include the following, '+' indicates must have, '-' indicates not possible / doesn't make sense (though might require noop stubs), '~' indicates would be nice if possible, '?' indicates unsure: + TIEHANDLE + PRINT + PRINTF + WRITE + READLINE + GETC + READ + CLOSE ? UNTIE ? DESTROY + BINMODE (noop) ? OPEN ~ EOF - FILENO ~ SEEK ~ TELL * maybe functions in xs/maps/(apache|apr)_functions.map 1.1 modperl-2.0/todo/design_notes Index: design_notes =================================================================== (dunno where to put it but don't want to lose these design notes, so just land them here for now) Filters: direct C api mapping -------------------- Apache::register_output_filter($filtername, $callback, $filter_type) Apache::register_input_filter($filtername, $callback, $filter_type) filter_type can be one of: Apache::FTYPE_CONTENT Apache::FTYPE_HTTP_HEADER Apache::FTYPE_TRANSCODE Apache::FTYPE_CONNECTION Apache::FTYPE_NETWORK $r->add_output_filter($name, $ctx) $c->add_output_filter($name, $ctx) $r->add_input_filter($name, $ctx) $c->add_input_filter($name, $ctx) note: $ctx will default to NULL Filters: directives ---------- PerlInputFilterHandler PerlOutputFilterHandler each will be the equivalent of: ap_register_{input,output}_filter($handler_name, $handler, $filter_type) where: $handler_name is the Perl name, at the moment is "MODPERL_OUTPUT" and "MODPERL_INPUT", would be easy to switch that to the handler name $handler is the modperl C callback $filter_type defaults to AP_FTYPE_CONTENT, subroutine attributes can be used to specify the filter_types list above based on attributes, add_{input,output}_filter may need to happen at different times, e.g. input filters who want to filter headers + content vs. input filters who want to filter only content alternative to those directives would be: PerlInputFilter PerlOutputFilter combined with: SetInputFilter SetOutputFilter pros: can use Perl{Input,Output}Filter to register the filter in httpd.conf, rather than using the API. can then call $r->add_{input,output}_filter($filter_name) at request time cons: in the common case, requires two directives that use the same values (the $handler_name) - and/or - PerlSetInputFilter PerlSetOutputFilter as aliases for SetInputFilter, SetOutputFilter which also take care of filter registration (which PerlInputFilter, PerlOutputFilter would have done) pros: similar to Set{Input,Output}Filter only need to use one directive cons: the filter module needs to register the filter in order to add the filter at request time without using a directive however: PerlModule Apache::FooFilter where Apache::FooFilter registers the filter, can provide this functionality without requiring new Perl{Input,Output}Filter directives - in any case - with the C api mapping it should be possible for a PerlModule to register the filter(s), then use the standard Set{Input,Output}Filter directives and the add_{input,output}_filter api at request time. note: no need to maintain a list of PerlFilters (like PerlModule, PerlRequire) since the directives trigger modperl_handler_new(), just like all other Perl*Handlers Filters: {get,set,push}_handlers ----------------------- would be nice for Perl{Input,Output}FilterHandler to work with the modperl {get,set,push}_handlers api just like other Perl*Handlers