httpd-apreq-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject cvs commit: httpd-apreq-2 STATUS
Date Fri, 30 May 2003 22:15:01 GMT
joes        2003/05/30 15:15:01

  Modified:    .        STATUS
  Log:
  Update status to reflect current state of glue/perl.
  
  Revision  Changes    Path
  1.7       +39 -10    httpd-apreq-2/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/httpd-apreq-2/STATUS,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- STATUS	6 May 2003 03:31:57 -0000	1.6
  +++ STATUS	30 May 2003 22:15:01 -0000	1.7
  @@ -26,11 +26,10 @@
              This behavior is unsafe, since large uploads can
              DOS the server by exhausting RAM.
   
  -        3. The req->upload API is unimplemented.
  +           [joes] How about writing an upload hook?
   
  -    * Filter API (env/mod_apreq.c) is missing key components:
   
  -        1. Safety features (see above).
  +        3. The req->upload API is unimplemented.
   
   
   CURRENT VOTES:
  @@ -39,11 +38,26 @@
   
   TODO:
   
  -    * Apache::Test tests in env/t.
  +    * Add documentation system.
  +
  +      [joes] suggests:
  +
  +      * doxygen for C API (header comments).
  +
  +      * perldoc for Perl glue (pod).
  +    
  +
  +    * Populate the glue/ directory.
  +
  +      * Port apreq-1's Apache::Test tests for the Perl API into glue/perl/t.
   
  -    * Populate the glue/ directory (perl, tcl, etc.).
  +      * ExtUtils::XSBuilder framework for glue/perl is in place.
  +        Now perl developers should be able to build & compile
  +        Request.xs & Cookie.xs.  The Apache::Test tests from apreq-1
  +        are really needed now to establish the API, and make it
  +        play nice with (& without) modperl-2.
   
  -    * add XForms logic to the mfd parser.
  +    * Add XForms logic to the mfd parser.
   
   
   OPEN ISSUES:
  @@ -51,7 +65,7 @@
     Documentation system.
   
     Should we bundle an apr-based "application/xml" parser?  
  -  If so, how should we parse the xml data into an apreq_table?
  +  If so, how should we parse the xml data into an apr_table?
   
   
   BUGS:
  @@ -61,5 +75,20 @@
   
   WISH LIST:
   
  -     APR should adopt our table implementation.  joes offered a patch to
  -     dev@apr on 4/28/2003 but it was apparently mistaken as porno-spam.
  +     [joes] I wish folks would contribute some glue code for
  +     one of these:
  +
  +              php, 
  +
  +              mod_tcl, 
  +
  +              mod_python, 
  +
  +              mod_jk, 
  +
  +              mod_ruby,
  +
  +              mod_parrot.
  +
  +     Someone should also adopt env/libapreq_cgi.c and ensure it
  +     donesn't fall into disrepair by adding some tests for it to env/t.
  
  
  

Mime
View raw message