Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
To: apreq list <apreq-dev@httpd.apache.org>
Subject: apreq-2 layout
From: Joe Schaefer <joe+apache@sunstarsys.com>
Date: 15 Jan 2003 23:21:14 -0500
Message-ID: <m3hec9hghx.fsf@mumonkan.sunstarsys.com>
Lines: 101
User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


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

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


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>

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