perl-modperl-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From s...@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
Date Mon, 17 Nov 2003 23:00:34 GMT
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 <Perl> 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: <Pine.LNX.4.33.0206201011070.2590-100000@mako.covalent.net>
    Status: <img alt="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.
  
  * <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
  
  * 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
    <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.
  
  
  - 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 <gozer@cpan.org>
    Status: Philippe M. Chiasson <gozer@cpan.org> 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
  
  
  
  
  

Mime
View raw message