cvs commit: modperl-2.0/todo possible_new_features.txt features_maybe

[st...@apache.org]

stas        2003/12/01 11:19:11

  Modified:    todo     possible_new_features.txt features_maybe
  Log:
  another reshuffle
  
  Revision  Changes    Path
  1.22      +0 -123    modperl-2.0/todo/possible_new_features.txt
  
  	<<Binary file>>
  
  
  1.3       +125 -0    modperl-2.0/todo/features_maybe
  
  Index: features_maybe
  ===================================================================
  RCS file: /home/cvs/modperl-2.0/todo/features_maybe,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -u -r1.2 -r1.3
  --- features_maybe	18 Nov 2003 21:45:18 -0000	1.2
  +++ features_maybe	1 Dec 2003 19:19:11 -0000	1.3
  @@ -33,3 +33,128 @@
     We could also have PerlServerCleanupHandler, but that's exactly what
     PerlChildExitHandler does. Consider having ServerCleanup as an alias.
   
  +config features:
  +----------------
  +
  +- tie %ENV to r->subprocess_env so stores are added to
  +  r->subprocess_env and fetches are looked up in there and elsewhere
  +  (e.g. HTTP_* from r->headers_in).  see modperl_env.c, current
  +  implementation is not threadsafe and requires 5.7.2+
  + 
  +- make 'PerlSetVar $Foo value' work like 'local $Foo = value' 
  +  for the given location
  +
  +- allow Perl*Handler's to have arguments in config files
  +
  +- allow <Perl></Perl> configuration sections to have read access to internal
  +  configuration structures (would be nice if we could tie a %namespace::) 
  +
  +- setuid/gid before running any Perl code
  +
  +- implement PerlINC (or similar) as a nicer interface for the working
  +  PerlSwitches -Mlib=/home/dev1/lib/perl, to set different @INC for
  +  different virtual hosts.
  +  See the thread: http://marc.theaimsgroup.com/?t=100554858800001&r=1&w=2
  +
  +- a possible implementation of PerlOptions +Inherit, similar to
  +  +Parent but which allows virtual hosts to inherit everything that
  +  was loaded by the main server, at the point of their definition in
  +  the config file. This can make it easier to write configuration
  +  files where there is a common base of modules to be loaded in all
  +  servers. Of course this can be done by putting all these common
  +  modules and code into foo.pl and running it from the base server and
  +  all virtual hosts.
  +
  +-  PerlModule can be made more efficient using Perl_load_module
  +
  +
  +
  +perl language features:
  +----------------------
  +
  +- @ARGV magic, tie to query string
  +
  +- sub handler : method ($) {}
  +  call $class->new($r) and pass the returned object as the first and
  +  only arg to the method handler
  +
  +- some mod_perlIO/PerlIO type methods for xs modules? (e.g. Apache::Peek)
  +
  +- possible to support BEGIN,CHECK,INIT blocks similar to how END is
  +  supported via ModPerl::Global::special_list_{call,clear}
  +
  +
  +
  +optimization features:
  +---------------------
  +
  +- copy-on-write SvPVX
  +
  +- hook Perl malloc into apr_pool
  +
  +- for "compiled handlers" w/ ithreads manage SV allocation via
  +  server-lifetime apr_pool_t
  +
  +- "garbage collector" thread to walk padlists looking for certain things
  +   worth releasing.
  +
  +- "mip manager" thread to watch # of active interpreters,
  +  cloning/destroying when needed (rather than waiting for a request to
  +  trigger)
  +
  +- use subpools per-callback/handler (might trim some memory bloat)
  +  note: creating subpools requires a malloc mutex lock with threaded
  +  mpms
  +
  +api:
  +---
  +
  +- improve the "stacked handlers" implementation, including:
  +  + allow push_handlers to have an additional argument, an array ref,
  +    which will be passed to the handler as arguments, e.g.
  +    $r->push_handlers("PerlHandler", \&some_sub, ['one', 'two', 'etc']);
  +
  +- might add an alias for $filter->connection (now we have $filter->c), to be
  +  more intuitive since we have $r->connection.
  +
  +modules:
  +-------
  +
  +- Apache::Registry should check return value of the subroutine,
  +  e.g. for REDIRECT   
  +
  +- should Apache::Registry use filename instead of vhost_name+uri?
  +
  +- core Apache::SubProcess w/ proper CORE::GLOBAL::{fork,exec} support
  +  + currently works only with $] >= 5.007003 (see the
  +    apache/subprocess test)
  +
  +- It's possible that we will add:
  +
  +  #ifdef MP_APACHE_COMPAT
  +       modperl_require_module("Apache::compat");
  +  #endif
  +
  +  if MP_APACHE_COMPAT Makefile.PL option is true. But this adds bloat,
  +  so this is just an option to consider.
  +
  +- Apache::File->tmpfile now lives only in compat. Consider adding
  +  APR::File->mktemp (apr_file_mktemp) and a perlio layer
  +  defined in terms of apr_file_t to use it.
  +
  +new modules:
  +-----------
  +
  +- apache.pm: use apache '1.3b3';
  +
  +misc new stuff:
  +--------------
  +
  +- 'make html'
  +
  +- 'make test_report'
  +
  +apache features that would be neat for mod_perl:
  +-----------------------------------------------
  +
  +- "autoload" hook for configuration directives
  \ No newline at end of file