| ##################### |
| # Registry Features # |
| ##################### |
| |
| - port Apache::PerlRunXS |
| |
| - replace the local implementation of finfo() when ported to mod_perl 2.0 |
| |
| - $r->chdir_file is not handled/implemented, see todo/api.txt unsafe! |
| |
| - $Apache::Server::CWD doesn't exist |
| |
| - need to figure out what's happening with |
| ModPerl::Registry::MarkLine, why it's not on by default? |
| |
| - a cousin of convert_script_to_compiled_handler() in 1.x used to have |
| 'undef &{"$o->[PACKAGE]\::handler"}' to avoid redefine handler() |
| warnings in case a user has used -w. also see the undef_functions on |
| the next line. |
| |
| - child_terminate is not implemented see |
| convert_script_to_compiled_handler(). |
| |
| - print STDERR is buffered in test handlers, whereas warn() works |
| normally. select() helps, but STDERR should be unbuffered in first |
| place. |
| |
| - in namespace_from_filename() should test whether a file is a symlink |
| and if so use readlink() to get the real filename. |
| |
| - documentation |
| |
| - acl support via 'filetest qw(access)'. It was decided that having |
| this feature by default will be too expensive, because of the |
| overhead it adds. The solution was to add a sub-class that will |
| provide that functionality. It wasn't decided whether it'll be in |
| the core or should live on CPAN. Also it wasn't decided whether |
| RegistryCooker should provide the necessary implementation |
| callbacks. See: |
| http://marc.theaimsgroup.com/?t=107636627000001&r=1&w=2 |
| |
| ### optimizations ### |
| |
| - currently the default is to strip __DATA__|__END__ and everything |
| after that, which incurs a little overhead because of the s/// on |
| the contents of the file. This "feature" wasn't in 1.x, so may |
| consider to make it optional. |
| |
| ### nice to have ### |
| |
| - Bjarni R. Einarsson <bre@klaki.net> has suggested this Registry hack |
| http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=98961929702745&w=2 |
| Message-ID: <20010511221101.A20868@diskordiah.mmedia.is> |
| |
| - the closure issue: |
| there was a suggestion from raptor to use goto() to leave the code |
| unwrapped in the sub handler, which will solve the closure problem, |
| but the problem is that once you leave a subroutine with goto() you |
| cannot return, because you aren't in the sub anymore. |
| |
| barrie has suggested a different approach, which requires adding |
| special tags to the script which help to parse the code, and shuffle |
| things around without putting subs inside the 'sub handler', but |
| this requires a lot of code understanding from a user, and if its |
| gained it's probably easier to fix the script so closure effect |
| won't happen. However barrie's suggestion can be easily added, by |
| overriding convert_script_to_compiled_handler(). |
| |
| - global variables persistance: could have the cooker option to flush |
| globals in the autogenerated package at the end of each |
| request. (not packages use()'d from this package) |
| |
| - could also try to privide an optional workaround for the problem |
| with libs collisions as explained here: |
| http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and |
| |
| - It's a known kludge with mod_perl scripts coming from mod_cgi which |
| use -M for file mtime comparisons, but are not aware of the fact |
| that $^T is not getting reset on each request. So may be the cooker |
| should have an option to reset $^T on each request. |
| |
| - develop a cooker() that cooks/modifies a registry package based on |
| PerlSetVar variables. So for example a user can modify a behavior of |
| an existing package (stat/donotstat...) and giving it a new name at |
| the same time. Kinda flag-based inheritance. |
| |
| * 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 |
| |