Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 29 May 2000 15:07:35 -0700 (PDT)
From: rbb@covalent.net
To: new-httpd@apache.org
Subject: Re: [PATCH] improving line number reporting for config file syntax
 errors
In-Reply-To: <Pine.LNX.4.10.10005291458570.14857-100000@nebula.lyra.org>
Message-ID: <Pine.LNX.4.21.0005291504500.18161-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> > Having looked at Jeff's patch again, what we really need to do, is to
> > combine the two patches.  Use an ap_directive_t to pass back the bad
> > directive, and re-write the line number in that ap_directive if we are
> > inside a container when we hit the error.
> 
> Rewrite it? Why did it have the wrong number in the first place!?!!

Because the current patch takes the beginning of the context, not the
actual directive that is causing the problem.

> > BTW, Does a line number actually make sense if we aren't using a
> > configfile?  Perhaps the configfile_t needs to be replaced with an iol
> 
> This is why we want to move away from a configfile_t whenever possible.
> 
> I don't know if an IOL is a perfect match (it is missing a line-based
> read), but yah: the basic concept is what we're looking for. I think what
> we really want is something like:

There is no reason to add another type, just add another function to
iol's.  This is much easier, and makes more sense IMHO.

The thing is that although we want to move away from actaully using
configfile_t, we will always have something like it in this structure.  We
should take advantage of that variable.  If use Jeff's patch, we ignore
the fact that there will always be a variable available that we can use
for error reporting.

Ryan

> struct ap_config_source_s ap_config_source_t;
> 
> ap_status_t ap_get_directive(ap_config_source_t *, ap_directive_t **);
> 
> Whatever. Basically: a way that we can ask for a directive at a time, from
> whatever the source happens to be. The only thing that we build in is the
> file-based config-per-line thingamajiggy.
> 
> There is more fallout/changes from this type of mechanism, but I'm not
> sure what they are. Just dropping out that quick thought for now.
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------