httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: proposed 2.0 features/layout (was Re: starting apreq 2.0)
Date Thu, 31 Jan 2002 09:28:31 GMT
Joe Schaefer wrote:

>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.
Sounds smart.

>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.
Well, I'm no expert on this, but that had overtones of shared libraries. 
 I can think of how to do this in C++ (provide an abstract parent class, 
who's definition can be used to dynamically allocate a subtype of that 
class), and Perl's even easier - I just did that for myself, actually 
(eval "use" and eval "Apache::Request::Parse::$parsemethod") but I have 
no idea how you can do this in C...

>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.
Are you talking about something in addition to the existing Perl 
Apache::Request->instance?   If not, why not leave it as is?  If so, why 
not code something siliar in C?

>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?

Not off the top of my head...  You might want to take the different MPMs 
into account and see if some things can be "enhanced" for different 
MPMs.  Same for core modules (eg, can apreq be helpful for an FTP core 
module? POP? IMAP?)


View raw message