httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Some thoughts on handles (was: Re: [PATCH] second snapshot of my "let's kill void*env" patch)
Date Fri, 14 Jan 2005 16:25:13 GMT
Max Kellermann <max@duempel.org> writes:

[...]

> - remove the second parameter from apreq_request() and apreq_cookie()

Actually, where I see the handle/module concepts 
heading is to the privatization of apreq_jar_t and 
apreq_request_t.  That's also a good idea, and it
seems to be a requirement if we're going to consider
situations where the "apreq module" implementation 
(mod_apreq) is executing in a separate thread from a 
libapreq2 client application.

The way I contemplate these things is from three standpoints:

  1) a libapreq2 user.  This person uses the library to
     gain access to cookies and params.  After selecting
     an appropriate module for his app, the only relevant
     API calls are

     a) possibly reconfigure the underlying environment module 
        (tempdir, post_max, change parsers, etc.).  These should
        all be implemented by the environment module itself (most
        already are), but the "change parsers" feature is exposed 
        through apreq_request_t.  That's a mistake in this context.

     b) request access to the parse data through the
        apreq_params.h or apreq_cookie.h API, and

     c) check for an errors which occurred during libapreq's
        attempt to service such requests.  Some of those
        errors will emerge from our parsers, some will come
        from the environment module, and others will come
        from libapr and libaprutil.


  2) an environment implementer.  This person needs to
     provide the relevant library callbacks, including 
     a means of pulling data from somewhere and feeding 
     it to the active parser.  He also defines the 
     sharing semantics for libapreq2 users, in terms of
     (a), (b), and (c) from #1.


  3) glue makers.  These guys try to make the #1 population 
     larger, but to be effective the glue needs to work
     in more than one environment.


The main reason I think the handle concept (and the ultimately the
privatization of apreq_request_t and apreq_jar_t) is a good idea
is because it makes the library more useful within the apache 
server itself.  Instead of keeping libapreq confined to a
request_rec, the handle idea could allow room for the development of 
an connection_rec-based environment within httpd itself, which
could be shared by an IO thread (#2 above) and a protocol 
filter (#1 above).

I could be totally off-base about that, but nevertheless the 
C API cleanup that's going on now is a good step in the right 
direction.  None of the changes under consideration here should
impact the perl API; but some of the implementation details will 
need to change a little bit (for the better).

Thoughts?

-- 
Joe Schaefer


Mime
View raw message