Return-Path: 
 <dev-return-60828-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: (qmail 40990 invoked from network); 3 Apr 2008 16:45:12 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 3 Apr 2008 16:45:12 -0000
Received: (qmail 7876 invoked by uid 500); 3 Apr 2008 16:45:09 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 7824 invoked by uid 500); 3 Apr 2008 16:45:09 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
List-Post: <mailto:dev@httpd.apache.org>
List-Id: <dev.httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 7813 invoked by uid 99); 3 Apr 2008 16:45:09 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Apr 2008 09:45:09 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [64.202.165.12] (HELO smtpout08.prod.mesa1.secureserver.net)
 (64.202.165.12)
    by apache.org (qpsmtpd/0.29) with SMTP; Thu, 03 Apr 2008 16:44:27 +0000
Received: (qmail 3493 invoked from network); 3 Apr 2008 16:44:22 -0000
Received: from unknown (71.239.140.137)
  by smtpout08-04.prod.mesa1.secureserver.net (64.202.165.12) with ESMTP;
 03 Apr 2008 16:44:21 -0000
Message-ID: <47F50964.1070505@rowe-clan.net>
Date: Thu, 03 Apr 2008 11:44:20 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
 configuration for the hackathon?])
References: <47F4FA06.5060604@rowe-clan.net>
	<C41A75BA.AD397%Brian.Akins@turner.com>
	<5c902b9e0804030859u147f18bdgaacd34f80bc1a3ed@mail.gmail.com>
	<47F5022B.7060700@rowe-clan.net> <20080403171833.395788ef@grimnir>
In-Reply-To: <20080403171833.395788ef@grimnir>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

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