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 apreq-2
Date Mon, 17 Jun 2002 18:28:42 GMT
Hi all.  Stas and I have been collaborating to get apreq ported
to apache-2.  We're testing & tweaking the C API right now, 
but I expect it to be solid in the next few days (it already passes 
the basic tests).  I've included the current README at the 
bottom of this post to outline the direction and goals of the port.
Within the next day or so I'll make the code available for scrutiny.

I'd like to solicit opinions NOW about how best to package and 
distribute the various API's.  The optimal solution, IMO, would 
be to bundle the C libraries with the apache-2 distribution (possibly 
as a module linked, statically or dynamically, to httpd).  The
Perl and Tcl language hooks can be distributed along with mod_perl 
or mod_dtcl.

What do you think?  And more importantly, would you be willing 
to help advocate apreq-2 's inclusion into apache-2 ?

% cat README
apreq-2

--------------------------------------------------
RATIONALE

libapreq arose from proof-of-concept mod_perl module (aka Apache::Request)
that was a direct C port of the CGI.pm perl codebase. However, over time 
the codebase has become increasingly complex and difficult to maintain.

One serious problem is that web browsers are buggy across differing 
vendors, versions, and platforms, but the current design isn't flexible 
enough to keep pace with such problems.

Another issue is that the standards for form submission are changing. 
XForms are on the way, which introduce the text/xml enctype.  It's 
likely that the programmer will want to specify a custom DOM parser 
for text/xml content.

apreq-2's redesign efforts are meant to address these needs.  The key
feature is that the programmer can now *override* the built-in parsers 
as needed- programmers can register new parsers that activate based on 
whatever (header-based) criterion is appropriate (e.g. enctype + 
method type, browser/cookie setting, etc.).

--------------------------------------------------
API CHANGES (outline)

superficial:
        prefix: Apache* -> apreq_*
        replaced: apache_multipart_buffer.* -> apreq_parser.*, apreq_list.*
        generic utilities & macros moved to apreq.[ch]
        conform to httpd-2 style & documentation guidelines

C API:

        apreq_request.h: replaced lots of old cruft with shiny, new cruft
        apreq_cookie.h:  relatively unchanged, divorced from apreq_request; 
                         needs better rfc compliance (e.g. Set-Cookie-2 ?)

Dependencies:
                                    +-< apreq_request.c
           +--< apreq_request.h <---+-< apreq_upload.c
           +--< apreq_list.h    <-+-+-< apreq_parser.c
apreq.h <--+--< apreq.c           +---< apreq_list.c
           +--< apreq_cookie.h  <-----< apreq_cookie.c

(Internal) Helper code:
        apreq_list.[ch]:
        manages the m/f-d parsing & buffering for apreq_parser.c
        frugal with ram: mallocs are kept to bare minimum
        MUCH commonality with apr_ring (or bucket brigade?), might
         wish to reimplement based on apr_*



Thanks in advance for your feedback!

Mime
View raw message