httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Date Thu, 03 Apr 2008 16:44:20 GMT
Nick Kew wrote:
> 
> But before that, we need a vision of where we're going,
> and how to get there without breaking what we've got.

  * server_conf goes away.  Modules have zero or more "conf" sections,
    essentially today's misnamed dir_conf, which are initialized and
    merged as they are today.  Either using simple-wrappers or custom.

  * we lose nothing, any module can rerun the conf merge conditionally
    (see mod_proxy today, or method, or the new <if implementation).

  * modules may pre-merge things to optimize them.  E.g. mod_vhost will
    pre-merge all of our <VirtualHosts > such that there is no run time
    penalty for vhosts.

  * particular merges should remain, as they are today, as a modular
    assemblage of features.  If your server will never serve files, there
    is no reason to compile in mod_filesystem e.g. <Files and <Dir mergers.
    No mod_vhost?  Then no <VirtualHost support.

  *** there must be sufficient hooks so that a lua, perl or m4 wrapper
      can participate in parsing the config.  TBD if that exists today.

> I don't see any such vision in this discussion.

Go back to my post from last night.  Not saying there's agreement, just
some vision.

I know folks are thinking "wow, I want to put my favorite [Lua] language
parser into httpd core!"  Well that's fine for some users, but at the
very same time, you have a huge crowd of perl users, mod_macro users, etc.

Based on httpd's design, you are SUPPOSED to be able to plug whichever
wrapper you like into the core.  Overloading the core is taking httpd
into an entirely different direction.  Just look at the effort we've
already expended is splitting cache from proxy, auth components from
one another, proxy capabilities from one monolithic module.

For that matter, plug in an XML syntax parser.  We aren't quite there
because we don't have the concept of named-arguments.  Fix that across
the entire spectrum of modules.  E.g. instead of TAKE2, we have some
tuple for alias such as (TAKE2, "uri-path", "file-path", NULL) which
will facilitate more deliberate parsers and conf authoring.  And that
is without breaking today's syntax.

Bill


Mime
View raw message