Return-Path: 
 <new-httpd-return-2332-apmail-new-httpd-archive=apache.org@apache.org>
Delivered-To: apmail-new-httpd-archive@apache.org
Received: (qmail 78444 invoked by uid 500); 12 Apr 2000 20:07:23 -0000
Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: new-httpd@apache.org
list-help: <mailto:new-httpd-help@apache.org>
list-unsubscribe: <mailto:new-httpd-unsubscribe@apache.org>
list-post: <mailto:new-httpd@apache.org>
Delivered-To: mailing list new-httpd@apache.org
Received: (qmail 78417 invoked from network); 12 Apr 2000 20:07:21 -0000
Date: Wed, 12 Apr 2000 13:13:15 -0700 (PDT)
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: [PATCH]  Config modules step 1
In-Reply-To: <Pine.LNX.4.21.0004120958380.14272-100000@koj.covalent.net>
Message-ID: <Pine.LNX.4.10.10004121309050.17315-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

On Wed, 12 Apr 2000 rbb@covalent.net wrote:
>...
> > A more intuitive tree would look like:
> > 
> >   Top-level directive
> >   Top-level directive
> >   <Directory /foo>
> >       Dir-level directive
> >       Dir-level directive
> >   Top-level directive
> 
> I actually agreed with you when I started, and about half way through, I
> decided I liked this better.  The tree itself denotes the containers,
> instead of the directives.  This puts everything related to a directory
> container on the same level of the tree.  I'm not married to either
> approach, so if you feel strongly about this let me know.

Yes, I do feel strongly about it :-)

Imagine the case where you're trying to find "/foo". You scan the
top-level quickly for it. There is no need to bounce down into child nodes
looking for the thing.

The top-level <Directory> is a directive that applies to the top-level, so
it should be a sibling of the other top-level directives. The config for
that directory is enclosed inside.

I could probably find a couple other reasons, but I'll stop now :-)

> One of the
> other things I like about the current approach is that we don't need to
> keep an extra pointer to the current pointer.  Depending on how complex
> your config is, that could be a lot of extra pointers that are really not
> necessary.

The current_parent is a static, just like current. Sorry that I didn't
make that clear. As a result, you don't end up with pointer bloat :-)

>...
> Can I assume that once all of the above issues are fixed, you are giving a
> +1 to this?

If the tree structure is changed, then I'm +1! Good stuff! :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/