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: 

