httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Aubrey <maur...@hevanet.com>
Subject Re: proposed 2.0 features/layout (was Re: starting apreq 2.0)
Date Thu, 31 Jan 2002 19:24:15 GMT
On Thu, Jan 31, 2002 at 11:28:31AM +0200, Issac Goldstand wrote:
> Joe Schaefer wrote:
> 
[snip]
> >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...

I think the idea is to just have a function, something
like apreq_register_enctype(), that accepts an enctype and
a function pointer.  And when a request is ready to be
parsed it will look up the enctype in that table and call
the appropriate function(s).

Maurice

Mime
View raw message