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
- [EMAIL PROTECTED] 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.
