Re: Pre-announce Apache::ConfigParser
- Original Message - From: Blair Zajac [EMAIL PROTECTED] To: Geoffrey Young [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 1:52 AM Subject: Re: Pre-announce Apache::ConfigParser Apache::Admin::Config Pros Cons Lack of documentation Test suite with 2 tests Purpose of this module was to parse, modify and write an apache (or apache like) configuration file without modifying the indentation and comments. It's very basic and not handle anything more than read, parse, write. More complexical module can be implemented on the top of it. The documentation is now writen, check at the 0.06 version : ftp://ftp.rhapsodyk.net/pub/devel/perl/Apache-Admin-Config-0.06.readme regards -- ___ O l i v i e rP o i t r e y USA disaster support http://www.osdn.com/911.shtml
Re: Pre-announce Apache::ConfigParser
Hi!
I swore there was yet a third candidate in this realm, but I didn't see it
on brief inspection.
I am currently sort of working (haven't touched for some time) on
something called Apache::FakeEnv which should be something like a subclass of
Apache::FakeRequest, but which includes access to stuff defined in Apache
Config Files.
I am now using Config::General to parse the config file, which works, but
as Config::General doesn't handle eg. PerlSetVar in the way I need it, I
have to do some dirty tricks to use the data structure returned from
Config::General
A feature I would really like to see (or implement myself in some combined
verions of the various Config parsers) is a way to take a parsed config
and an URL and to get all values that apply to this URL
eg:
Location /test/
PerlSetVar foo bar
PerlSetVar baz bla
/Location
LocationMatch something
PerlSetVar foo NotBar
/LocationMatch
$conf-requested_uri('http://host/test/somehting/');
print $conf-dir_config('foo'); # prints 'NotBar'
print $conf-dir_config('baz'); # prints 'bla'
So, if there will be an Unified Apache Config Parsing Module, I would like
to implement this feature (if it's not allready there ...)
domm
RE: Pre-announce Apache::ConfigParser
I swore there was yet a third candidate in this realm, but I didn't see it on brief inspection. Config::General also parses Apache-style config files, but I don't think it handles Apache specific details like contexts. Michael
Pre-announce Apache::ConfigParser
Hello,
This is a preannounce of Apache::ConfigParser. I wrote this to
allow programs separate from Apache to completely understand,
parse and manipulate Apache configuration files.
The interface is not simple, but it allows for more complicated
understanding of log files, such as finding the associated ServerName
for log files.
There are two separate modules described here. The first manages
a single directive and the second assembles these into an object
that represents a complete configuration file.
Comments welcome, including the name of the module.
It's available now at
http://www.orcaware.com/perl/Apache-ConfigParser-0.01.tar.gz
and will be up on CPAN if there are no serious comments.
Regards,
Blair
NAME
Apache::ConfigParser::Directive - An Apache directive or start
context
SYNOPSIS
use Apache::ConfigParser::Directive;
# Create a new emtpy directive.
my $d = Apache::ConfigParser::Directive-new;
# Make it a ServerRoot directive.
# ServerRoot /etc/httpd
$d-name('ServerRoot');
$d-value('/etc/httpd');
# A more complicated directive. Value automatically splits the
# argument into separate elements. It treats elements in 's
as a
# single ement.
# LogFormat %h %l %u %t \%r\ %s %b common
$d-name('LogFormat');
$d-value('%h %l %u %t \%r\ %s %b common');
# Get a string form of the name.
# Prints `logformat'.
print $d-name, \n;
# Get a string form of the value.
# Prints `%h %l %u %t \%r\ %s %b common'.
print $d-value, \n;
# Get the values separated into individual elements.
Whitespace
# separated elements that are enclosed in 's are treated as a
# single element. Protected quotes, \, are honored to not
begin or
# end a value element. In this form protected 's, \, are no
# longer protected.
my @value = $d-get_value_array;
scalar @value == 2; # There are two elements in this
array.
$value[0] eq '%h %l %u %t \%r\ %s %b';
$value[1] eq 'common';
# The array form can also be set. Change style of LogFormat
from a
# common to a referer style log.
$d-set_value_array('%{Referer}i - %U', 'referer');
# This is equivalent.
$d-value('%{Referer}i - %U referer');
# There are also an equivalent pair of values that are called
# `original' that can be accessed via orig_value,
# get_orig_value_array and set_orig_value_array.
$d-orig_value('%{User-agent}i agent');
$d-set_orig_value_array('%{User-agent}i', 'agent');
@value = $d-get_orig_value_array;
scalar @value == 2; # There are two elements in this
array.
$value[0] eq '%{User-agent}i';
$value[1] eq 'agent';
# You can set undef values for the strings.
$d-value(undef);
DESCRIPTION
The Apache::ConfigParser::Directive module is a subclass
of Tree::DAG_Node, which provides methods to represents
nodes in a tree. Each node is a single Apache configura
tion directive or root node for a context, such as Direc
tory or VirtualHost. All of the methods in that module
are available here. This module adds some additional
methods that make it easier to represent Apache directives
and contexts.
This module holds a directive or context:
name
value in string form
value in array form
a separate value termed `original' in string form
a separate value termed `original' in array form
the filename where the directive was set
the line number in the filename where the directive was set
The `original' value is separate from the non-`original'
value and the methods to operate on the two sets of values
have distinct names. The `original' value can be used to
store the original value of a directive while the
non-`directive' value can be a modified form, such as
changing the CustomLog filename to make it absolute. The
actual use of these two distinct values is up to the
caller as this module does not link the two in any way.
METHODS
The following methods are available:
$d = Apache::ConfigParser::Directive-new;
This creates a brand new Apache::ConfigParser::Direc
tive object.
It is not recommended to pass any arguments to new
to set the internal state and instead use the follow
ing methods.
There actually is no new method in the Apache::Con
figParser::Directive module. Instead, due to
Apache::ConfigParser::Directive being a subclass of
Tree::DAG_Node, Tree::DAG_Node::new will be used.
$d-name
$d-name($name)
In the first form get
RE: Pre-announce Apache::ConfigParser
-Original Message- From: Blair Zajac To: [EMAIL PROTECTED] Sent: 9/12/01 5:41 PM Subject: Pre-announce Apache::ConfigParser Hello, This is a preannounce of Apache::ConfigParser. I wrote this to allow programs separate from Apache to completely understand, parse and manipulate Apache configuration files. BTW, I appreciate you posting an RFC, mainly because I feel as though the Apache module list has grown rapidly of late (which is not necessarily a bad thing) but grown without that many RFCs, feedback, or attempts to build on what others have already done. that said, is this all that different from CPAN/modules/by-module/Apache/Apache-Admin-Config-0.05.tar.gz ? I swore there was yet a third candidate in this realm, but I didn't see it on brief inspection. at any rate, can the two somehow be integrated into some mutually acceptable module? --Geoff
Re: Pre-announce Apache::ConfigParser
I missed the Apache-Admin-Config module in my search for Apache config file parsers, otherwise I would have not written a new one :) The other parser was just announced after I finished this one is named Apache::ConfigFile. All three modules appear to treat the directives and contexts the same, in that you can descend into the contexts to get directive's specified there. They could definitely be merged into a single module that does what everybody needs. I don't have the time to do this myself, but would could help out. A common API would have to be designed so that it would have all of the features people needed. Here's a quick review of the pluses and minuses of the tree modules (obviously pro Apache::ConfigParser because it has the features I need). Apache::Admin::Config Pros Cons Lack of documentation Test suite with 2 tests Apache::ConfigFile Pros Clear interface Good documentation Handles mod_perl Perl config directives Overloaded method names to get config values Automatic boolean conversion Been around for a while Cons Test suite with one test Apache::ConfigParser Pro Good documentation Build tree structure of config allowing complicated searches Parses config file exactly as Apache does Knows which directives can take relative path names and makes them absolute automatically Correctly parses directive values with 's and \'s Allows searches on directives regardless of context Allows searches up through context levels Extensive test suite Keeps track of where directives were set Cons Doesn't write out config files No autoloaded calls Not easily used interface Is it possible to remove CPAN modules when a common interface is built? Blair Geoffrey Young wrote: -Original Message- From: Blair Zajac To: [EMAIL PROTECTED] Sent: 9/12/01 5:41 PM Subject: Pre-announce Apache::ConfigParser Hello, This is a preannounce of Apache::ConfigParser. I wrote this to allow programs separate from Apache to completely understand, parse and manipulate Apache configuration files. BTW, I appreciate you posting an RFC, mainly because I feel as though the Apache module list has grown rapidly of late (which is not necessarily a bad thing) but grown without that many RFCs, feedback, or attempts to build on what others have already done. that said, is this all that different from CPAN/modules/by-module/Apache/Apache-Admin-Config-0.05.tar.gz ? I swore there was yet a third candidate in this realm, but I didn't see it on brief inspection. at any rate, can the two somehow be integrated into some mutually acceptable module? --Geoff
RE: Pre-announce Apache::ConfigParser
I'll let the other module authors answer your API questions - I was merely starting the dialogue :) Is it possible to remove CPAN modules when a common interface is built? yes, PAUSE has a delete interface, which removes them from the various CPAN mirrors. there is also an archive project going on at PAUSE somewhere, which has all the modules every uploaded (or something like that) I have a module or two out there I ought to clean up myself ;) --Geoff
