STATUS - mod_perl - Git at Google

 mod_perl 2.0 STATUS:                                       -*-text-*-
    Last modified at [$Date: 2003/10/27 14:12:03 $]

 Release:
 --------

    1.99_10    : Released Sep 30, 2003
    1.99_09    : Released Apr 28, 2003
    1.99_08    : Released Jan 10, 2003
    1.99_07    : Released Sep 27, 2002
    1.99_06    : Not released
    1.99_05    : Released Aug 20, 2002
    1.99_04    : Released Jun 21, 2002
    1.99_03    : Released Jun 16, 2002
    1.99_02    : Released Jun 01, 2002
    1.99_01    : Released Apr 06, 2002


    ====================================================
    === We are still using the todo/ directory to    ===
    === track some status; please look there too ... ===
    ====================================================


 Release Showstoppers:
 ---------------------

 Available Patches:
 ------------------

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

 * The Apache::Scoreboard XS implemenation with tests is awaiting to be
   committed

   Report: http://mathforum.org/epigone/modperl-dev/zehporbreh/Pine.LNX.4.44.0204062240010.11967-100000@hope.stason.org
   Status: (stas) needs to be cleaned up and committed

 ----

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


 Platforms on which mod_perl won't build/load
 --------------------------------------------

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


 Needs Patch or Further Investigation:
 -------------------------------------
 * per-server cleanups core dump or are otherwise ineffective
     Apache->server->process->pconf->cleanup_register(sub { ...  });

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

 * <Perl> sections:
   A few issues with <Perl> sections:
   http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106074969831522&w=2

 * Recursive <Perl> 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

 * PassEnv/SetEnv propogation
   http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/%5BMP2_BUG%5D_PerlPassEnv_issues_P70500/

 * 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

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

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

 * this is probably a documenation issue. Several phases are of type VOID
   and docs say:

     Handlers of the type C<VOID> will be I<all> executed in the order they
     have been registered disregarding their return values. Though in
     mod_perl they are expected to return C<Apache::OK>.

   may be we shouldn't mark them as VOID then, but RUN_ALL? this is in
   user/handlers/intro.pod

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

 * '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/)

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

 * 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

 * we still have a problem with mod_perl starting from a
   vhost. consider the following config:

   PerlSwitches -I/foo/bar
   <VirtualHost TestDirective::perlloadmodule6>
      PerlLoadModule TestDirective::perlloadmodule6
      ...
   </VirtualHost>

   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.

 * 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

 * $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.

 * 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::info for CmdParms implemented by Perl modules

   - Apache::CmdParms::{GETC,getline} needs compat mapping, similar to
     what Apache::Directive->as_string does, but one char or line at a time

 * Quite a few people reported problems with TestHooks during 'make test'
   - http://marc.theaimsgroup.com/?t=102985405500008&r=1&w=2

 * the issue with crypt_r: in 5.8.0's each perl clone allocates 128K
   for crypt_data. This fixed in 5.8.1 and 5.9.0 (#19119 (maint) and
   #19122 (blead)), however this could be quite a waste for those using
   5.8.0. perhaps adding a note to performance chapter will do. For
   more info see the thread:
   http://archive.develooper.com/perl5-porters@perl.org/msg93846.html

 Open Issues or Core Enhancements:
 ---------------------------------

 * 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).

 * 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

 * 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()]

   Report: Message-ID: <Pine.LNX.4.33.0206201011070.2590-100000@mako.covalent.net>
   Status: <img alt="Doug, contemplating">

 ----

 * we need a bug reporting utility that can be used post-install, which
   should be similar to t/REPORT

   Report: http://mathforum.org/epigone/modperl-dev/staiblirroo/3CB544D7.8040109@stason.org
   thread: http://mathforum.org/epigone/modperl-dev/staiblirroo
   Status: +1: Stas, Doug
           needs to be implemented

 ----

 * Apache::PerlSections missing features for backwards compatibility:
  - $Apache::ReadConfig::DocumentRoot
  - Apache::PerlSections->store(filename)

   Report: Philippe M. Chiasson <gozer@cpan.org>
   Status: Philippe M. Chiasson <gozer@cpan.org> is working on it

 ----

 * PerlPreConnectionHandler is implemented, but the 'void *csd' arg in
   the callback is ignored

   Status: no hurry

 ----

 *
   Report:
   Status:

 ----

 APR as external Perl glue
 -------------------------

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

 Documentation:
 --------------

   -- see: modperl-docs/src/docs/2.0/TODO

 Patches unlikely to be applied:
 -------------------------------

 *
   Report:
   Status:
	mod_perl 2.0 STATUS: --text--
	Last modified at [$Date: 2003/10/27 14:12:03 $]

	Release:
	--------

	1.99_10 : Released Sep 30, 2003
	1.99_09 : Released Apr 28, 2003
	1.99_08 : Released Jan 10, 2003
	1.99_07 : Released Sep 27, 2002
	1.99_06 : Not released
	1.99_05 : Released Aug 20, 2002
	1.99_04 : Released Jun 21, 2002
	1.99_03 : Released Jun 16, 2002
	1.99_02 : Released Jun 01, 2002
	1.99_01 : Released Apr 06, 2002


	====================================================
	=== We are still using the todo/ directory to ===
	=== track some status; please look there too ... ===
	====================================================



	Release Showstoppers:
	---------------------

	Available Patches:
	------------------

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

	* The Apache::Scoreboard XS implemenation with tests is awaiting to be
	committed

	Report: http://mathforum.org/epigone/modperl-dev/zehporbreh/Pine.LNX.4.44.0204062240010.11967-100000@hope.stason.org
	Status: (stas) needs to be cleaned up and committed

	----

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





	Platforms on which mod_perl won't build/load
	--------------------------------------------

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


	Needs Patch or Further Investigation:
	-------------------------------------
	* per-server cleanups core dump or are otherwise ineffective
	Apache->server->process->pconf->cleanup_register(sub { ... });

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

	* <Perl> sections:
	A few issues with <Perl> sections:
	http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106074969831522&w=2

	* Recursive <Perl> 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

	* PassEnv/SetEnv propogation
	http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/%5BMP2_BUG%5D_PerlPassEnv_issues_P70500/

	* 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

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

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

	* this is probably a documenation issue. Several phases are of type VOID
	and docs say:

	Handlers of the type C<VOID> will be I<all> executed in the order they
	have been registered disregarding their return values. Though in
	mod_perl they are expected to return C<Apache::OK>.

	may be we shouldn't mark them as VOID then, but RUN_ALL? this is in
	user/handlers/intro.pod

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

	* '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/)

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

	* 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

	* we still have a problem with mod_perl starting from a
	vhost. consider the following config:

	PerlSwitches -I/foo/bar
	<VirtualHost TestDirective::perlloadmodule6>
	PerlLoadModule TestDirective::perlloadmodule6
	...
	</VirtualHost>

	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.

	* 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

	* $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.

	* 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::info for CmdParms implemented by Perl modules

	- Apache::CmdParms::{GETC,getline} needs compat mapping, similar to
	what Apache::Directive->as_string does, but one char or line at a time

	* Quite a few people reported problems with TestHooks during 'make test'
	- http://marc.theaimsgroup.com/?t=102985405500008&r=1&w=2

	* the issue with crypt_r: in 5.8.0's each perl clone allocates 128K
	for crypt_data. This fixed in 5.8.1 and 5.9.0 (#19119 (maint) and
	#19122 (blead)), however this could be quite a waste for those using
	5.8.0. perhaps adding a note to performance chapter will do. For
	more info see the thread:
	http://archive.develooper.com/perl5-porters@perl.org/msg93846.html

	Open Issues or Core Enhancements:
	---------------------------------

	* 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).

	* 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

	* 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()]

	Report: Message-ID: <Pine.LNX.4.33.0206201011070.2590-100000@mako.covalent.net>
	Status: <img alt="Doug, contemplating">

	----

	* we need a bug reporting utility that can be used post-install, which
	should be similar to t/REPORT

	Report: http://mathforum.org/epigone/modperl-dev/staiblirroo/3CB544D7.8040109@stason.org
	thread: http://mathforum.org/epigone/modperl-dev/staiblirroo
	Status: +1: Stas, Doug
	needs to be implemented

	----

	* Apache::PerlSections missing features for backwards compatibility:
	- $Apache::ReadConfig::DocumentRoot
	- Apache::PerlSections->store(filename)

	Report: Philippe M. Chiasson <gozer@cpan.org>
	Status: Philippe M. Chiasson <gozer@cpan.org> is working on it

	----

	* PerlPreConnectionHandler is implemented, but the 'void *csd' arg in
	the callback is ignored

	Status: no hurry

	----

	*
	Report:
	Status:

	----

	APR as external Perl glue
	-------------------------

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

	Documentation:
	--------------

	-- see: modperl-docs/src/docs/2.0/TODO

	Patches unlikely to be applied:
	-------------------------------

	*
	Report:
	Status: