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: PerlSetVar foo bar PerlSetVar baz bla PerlSetVar foo NotBar $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
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
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 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
>-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