httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: apreq-2 layout
Date Thu, 16 Jan 2003 04:33:21 GMT
Joe Schaefer wrote:
> Here are a few things I've decided to try for httpd-apreq-2.
> Comments appreciated.
> 
> httpd-apreq-2/src/
> 
>   This is the core APR-based part of apreq-2.  I'm refactoring
>   my code a bit to pull out the httpd dependencies.  For now
>   the httpd-specific code will be moved somewhere into env/.
> 
> httpd-apreq-2/env/
> 
>   This is where the real "porting" is done.  Conceivably apache-1.3,
>   apache-2.0, and apache-2.2 can all be independently bound to the 
>   apreq-2 core, as could other environments like CGI.
> 
>   ( Note: If the "split" doesn't work out, we can drop env/ and
>   put the httpd dependencies back into src/. )

Since it's not going to be a drop-in patch anymore, the biggest trouble is 
to produce the new autoconf m4 files to find apr/apr-util/apache. 
Hopefully the relevant code can be ripped of mod_perl 2.0.

>   So far, I'm basing the split on the following vtables:
>   --------------------------------------------------
>   struct apreq_request_env {
>     apreq_request_t *(*make)(void *ctx);
>     apr_status_t (*init)(void *ctx, apreq_parser_cfg_t *cfg);
>     apr_status_t (*parse)(apreq_request_t *req);
>   };
> 
>   struct apreq_cookie_env {
>     const char *(*in)(void *ctx);
>     const char *(*in2)(void *ctx);
> 
>     apr_status_t (*out)(void *ctx, char *c);
>     apr_status_t (*out2)(void *ctx, char *c);
>   };
> 
>   struct apreq_env {
>     struct apreq_request_env r;
>     struct apreq_cookie_env  c;
>     apr_pool_t *(*pool)(void *ctx);
>     void (*log)(const char *file, int line, int level, 
>                 apr_status_t status, void *ctx, const char *fmt, ...);
>   };
>   --------------------------------------------------
>   With this setup, "porting apreq-2" is basically a 
>   matter of populating the global variable "APReq":
> 
>     extern struct apreq_env APReq;

Careful with globals. We are potentially running in a threaded env in 2.0. 
I'd rather see a compile time resolving.

>   The actual details will get spelled out in src/apreq_env.h,
>   but this is *very* rough at the moment (particularly the 
>   apreq_request_env struct).
> 
> 
> httpd-apreq-2/glue/
> 
>   This is where the language bindings will go. The glue should 
>   provide interfaces for most of the stuff in src/, 
>   and treat the code in env/ as optional.  Ideally apreq-2 ports 
>   will work without any coaxing, so the env/ code shouldn't
>   *need* glue.
> 
>   For example, here's some sketchy ideas for the perl glue:
> 
>   conventional (modperl) APIs:
> 
>     Apache::Request     These may need some env/ glue, since they are
>     Apache::Cookie      modperl-specific.
> 
> 
>   new (abstract) APIs:
> 
>     APReq::Table        data store (very similar to APR::Table)
> 
>     APReq::Cookie       Apache::Cookie, without the CGI::Cookie 
>                         semantics for cookie-value encoding
> 
>     APReq::Request      Apache::Request without Apache as its base class.
>                         For modperl, APReq::Request will probably need to 
>                         use delegation, not inheritance ( similar to DBI )
>                         to get at the Apache->request methods.
>                         Programs that use APReq:: modules should be
>                         maximally portable to other environments.
> 
> The XS for the new modules should be environment-agnostic, so code
> that uses only these modules should be portable to other environments
> (well, that's my theory :-).
> 
> <issue type="bikeshed">
>   Oh yeah, are there any preferences on the capitalization of apreq for the 
>   perl-module namespace?  I'm using APReq here and there now, and I much
>   prefer it over "ApReq".  Another alternative is APREQ, which would be
>   ok with me.
> </issue>

I'm -0 on APReq as it's too similar to APR. Both APREQ and ApReq are fine 
with me. AR sounds cool too, but that won't map well into apreq_.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message