httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject apreq-2 layout
Date Thu, 16 Jan 2003 04:21:14 GMT

Here are a few things I've decided to try for httpd-apreq-2.
Comments appreciated.


  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/.


  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/. )

  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;

  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).


  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.

Ok, that's probably enough vagaries for now.  Unless there's 
serious objections to this layout, I'll start dumping code
into src/.

Joe Schaefer

View raw message