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 22:52:17 GMT
Maurice Aubrey wrote:

>On Thu, Jan 31, 2002 at 11:28:31AM +0200, Issac Goldstand wrote:
>>Joe Schaefer wrote:
>>>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).
So it would be registered at apache startup using a callback in some 
other apache module?  If not, what's going to register the function?  If 
so, does that mean that an apache module has to be created for each 
enctype (or "bundle" of enctypes)?


View raw message