httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+apa...@sunstarsys.com>
Subject proposed 2.0 features/layout (was Re: starting apreq 2.0)
Date Thu, 31 Jan 2002 03:34:47 GMT

Here's a list of proposed changes to the C API; please comment

1) use "apreq_" as the generic prefix for files and functions
in the c api.

e.g. structs like ApacheCookie and ApacheRequest replaced
by apreq_cookie_t and apreq_request_t; functions names 
and macros map similarly

  ApacheRequest_new      -> apreq_request_new
  ApacheCookieJarFetch   -> apreq_cookie_jar_fetch

The current header files are inconsistent and have
too much cruft.  Although I prefer using a common
naming convention for both macros and functions within
header files, I could live with adopting a different
scheme for macros.  But the current .h files are not
consistent in this regard, and IMO that needs to change.

2) (user-extensible) enctypes for POST data
  a) www-urlencoded
  b) multipart/form-data
  c) xml types?

Currently the logic for parsing form-data is tangled 
between apache_request.c and apache_multipart_buffer.c;
I'd like to see that replaced by a generic mechanism that
extracts all the particulars for parsing a given enctype
*out* of apache_request.c.  IOW an end-user should be able to 
"register" an enctype with apreq and provide hooks to 
handle the data parsing.  Of course we should provide support 
for the most commonly used ones, but I think we should use the 
same interface as an end user would for this.

3) persistence across various apache phases?

Just a thought- we don't offer this with apreq 1.0, but we 
could offer some internal support for an instance() in 2.0.

4) random goals for improvement:

1) better rfc compliance
2) user-tunable resource management (RAM, temp files, etc.)
3) handle chunked data gracefully

Any other cool/useful features we should consider?

-- 
Joe Schaefer



Mime
View raw message