Re: Apache::Config module
On Tue, 27 Jun 2000, Nathan Wiger wrote: > Hi all- > > I've written a module that can parse the Apache httpd.conf config file > (and in fact any Apache-like config file). It will take a set of > directive like: > > ServerName www.mydomain.com > UseCanonicalName Off > > And parse it case-insensitively, returning a ref to a hash: > > my $ac = new Apache::Config; > my $conf = $ac->readconf($configfile); > print $conf->{servername}; # = "www.mydomain.com"; > print $conf->{usecanonicalname}; # = 0 (not undef so can test > #for defined() still) it would be really cool if this module could support dumping of a parsed config file into the same format that sections understand. and the other way around, dumping a section back into a .conf that Apache can read without sections. > In any case, I have several questions: > > 1. Does a module like this exist anywhere? I saw Doug's >Apache::httpd_conf, but this only takes care of writing >a very minimal config file. I looked thru all the >Apache:: modules but didn't see one. yeah, Apache::httpd_conf was something that was started and never finished. i think ken williams is working on something in this area, for modules to write test config files. > 2. Is the name Apache::Config a good name for this module? >It seems like the obvious choice to me, and doesn't >look like it's taken. I've also played around with >Apache::ConfigFile and Apache::ReadConf, either of >which I'm open to as well (or other suggestions?). i'd go with Apache::ConfigFile.
Re: Apache::Config module
>> No wonder Nathan Wiger on Jun 29 said that, NW] > NW] In any case, I have several questions: NW] > NW] NW] > NW] 1. Does a module like this exist anywhere? NW] > NW] > You may want to take a look at AppConfig module. It does provide NW] > generic capability to parse various kinds of config file. But I'll NW] > be a happy user to have more spesific Apache related in this regard. NW] NW] Yeah, I checked out AppConfig, and I actually emailed the author about NW] modifying it a little so I could use it as a base class possibly for NW] Apache::Config. Unfortunately, I haven't heard anything back yet. NW] AppConfig would be a great base class, the only problem is that: NW] NW] # it handles comments like this NW] NW] # but not like this NW] NW] that's the only sticking point to not being able to extend AppConfig. NW] Hopefully I'll hear something back from him. The fix is just the NW] addition of a \s* to a regexp. Yeah, at least the author could let the subclass to override some aspects. The comment for example, smb.conf and php.ini use `;' as well. NW] > Apache::Config will be sufficient, IMHO, as later someone might NW] > write another module, say Apache::Config::Deploy, that syncronize NW] > the configuration of some httpds across some networks. NW] NW] Not bad - I like the idea for an extension. NW] NW] I'll keep plugging away on it then, hopefully the author of AppConfig NW] will get back to me as that would help save some work, but regardless NW] the parsing of the httpd.conf is not really that hard in and of itself. NW] I'll use the name Apache::Config unless I hear otherwise. So you may want to take a time to confirm the name to [EMAIL PROTECTED] NW] Thanks again to everyone who responded for their input! Good luck with the project! san -- trabasLabs * [EMAIL PROTECTED] * http://www.trabas.com Zero Point * [EMAIL PROTECTED] * http://www.zp.f2s.com -- Kesenian hanyalah dusta, dusta yang mengungkap kebenaran --Plato, kurang lebih
Re: Apache::Config module
> NW] In any case, I have several questions: > NW] > NW] 1. Does a module like this exist anywhere? > > You may want to take a look at AppConfig module. It does provide > generic capability to parse various kinds of config file. But I'll > be a happy user to have more spesific Apache related in this regard. Yeah, I checked out AppConfig, and I actually emailed the author about modifying it a little so I could use it as a base class possibly for Apache::Config. Unfortunately, I haven't heard anything back yet. AppConfig would be a great base class, the only problem is that: # it handles comments like this # but not like this that's the only sticking point to not being able to extend AppConfig. Hopefully I'll hear something back from him. The fix is just the addition of a \s* to a regexp. > Apache::Config will be sufficient, IMHO, as later someone might > write another module, say Apache::Config::Deploy, that syncronize > the configuration of some httpds across some networks. Not bad - I like the idea for an extension. I'll keep plugging away on it then, hopefully the author of AppConfig will get back to me as that would help save some work, but regardless the parsing of the httpd.conf is not really that hard in and of itself. I'll use the name Apache::Config unless I hear otherwise. Thanks again to everyone who responded for their input! -Nate
Re: Apache::Config module
James- You and are are saying the same thing, just with different terminology. I agree completely. :-) -Nate James G Smith wrote: > > Nathan Wiger <[EMAIL PROTECTED]> wrote: > > > > UseCanonicalName On# = 1 > > UseCanonicalName Off # = 0 > > #UseCanonicalName On# = undef (commented out) > > > >That way, the logic in your script/module/whatever can set a default > >value: > > > > if ( ! defined($conf->{usecanonicalname}) ) { > > # not specified, set default(s) > > } elsif ( ! $conf->{usecanonicalname} ) { > > # explicitly turned off > > } else { > > # explicitly turned on > > } > > I think I would prefer it not exist in the hash if it is commented out in the > config file (the same as not existing in the config file). Then > > UseCanonicalName On# = 1 > UseCanonicalName Off # = 0 > UseCanonicalName # = undef > #UseCanonicalName On# = non-existant (commented out) > > Otherwise, we can't distinguish between the last two possibilities. > -- > James Smith <[EMAIL PROTECTED]>, 979-862-3725 > Texas A&M CIS Operating Systems Group, Unix
Re: Apache::Config module
>> No wonder Nathan Wiger on Jun 27 said that, NW] Hi all- NW] NW] I've written a module that can parse the Apache httpd.conf config file NW] (and in fact any Apache-like config file). It will take a set of NW] directive like: NW] NW] ServerName www.mydomain.com NW] UseCanonicalName Off NW] NW] And parse it case-insensitively, returning a ref to a hash: NW] NW] my $ac = new Apache::Config; NW] my $conf = $ac->readconf($configfile); NW] print $conf->{servername}; # = "www.mydomain.com"; NW] print $conf->{usecanonicalname}; # = 0 (not undef so can test NW] #for defined() still) NW] NW] I am also finishing up the ability to parse within contexts, such as NW] and . I am still unsure of the interface, I have NW] two ideas: NW] NW] 1. multi-level hash, i.e. NW] $conf->{"directory /"}->{sethandler} NW] NW] 2. individual functions, i.e. NW] $conf->directory("/")->{sethandler} NW] NW] If anyone has any input, I'm all ears. Right now I'm leaning towards the NW] second one, if I can get it working. The first one is really flexible NW] and easy, the problem is that it's difficult to search. The second one NW] helps with this issue, but the downside is that new functions have to be NW] added if new Apache contexts are defined. I'm trying to play some tricks NW] with the AutoLoader ala Shell to get new functions defined on the fly. NW] If anyone has good ideas for a better interface, I'd also like to hear NW] them. NW] NW] In any case, I have several questions: NW] NW] 1. Does a module like this exist anywhere? I saw Doug's NW]Apache::httpd_conf, but this only takes care of writing NW]a very minimal config file. I looked thru all the NW]Apache:: modules but didn't see one. You may want to take a look at AppConfig module. It does provide generic capability to parse various kinds of config file. But I'll be a happy user to have more spesific Apache related in this regard. NW] NW] 2. Is the name Apache::Config a good name for this module? NW]It seems like the obvious choice to me, and doesn't NW]look like it's taken. I've also played around with NW]Apache::ConfigFile and Apache::ReadConf, either of NW]which I'm open to as well (or other suggestions?). Apache::Config will be sufficient, IMHO, as later someone might write another module, say Apache::Config::Deploy, that syncronize the configuration of some httpds across some networks. [snip] san -- trabasLabs * [EMAIL PROTECTED] * http://www.trabas.com Zero Point * [EMAIL PROTECTED] * http://www.zp.f2s.com -- bahkan mahasiswa yang memperjuangkan reformasi pun masih menempatkan wanita pada posisi inferior --Sudjiwo Tejo 14/12/1998 tentang kiriman ayam betina kepada Jaksa Agung
Re: Apache::Config module
Nathan Wiger <[EMAIL PROTECTED]> wrote: > > UseCanonicalName On# = 1 > UseCanonicalName Off # = 0 > #UseCanonicalName On# = undef (commented out) > >That way, the logic in your script/module/whatever can set a default >value: > > if ( ! defined($conf->{usecanonicalname}) ) { > # not specified, set default(s) > } elsif ( ! $conf->{usecanonicalname} ) { > # explicitly turned off > } else { > # explicitly turned on > } I think I would prefer it not exist in the hash if it is commented out in the config file (the same as not existing in the config file). Then UseCanonicalName On# = 1 UseCanonicalName Off # = 0 UseCanonicalName # = undef #UseCanonicalName On# = non-existant (commented out) Otherwise, we can't distinguish between the last two possibilities. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Re: Apache::Config module
> > Perhaps > > > > 3. multi-level hash, i.e. > >$conf->{directory}->{'/'}->{sethandler} > > > > This is, afaik, more in-line with what the ... sections do. I > > would suggest making it so the output of this module could easily be fed into > > the mod_perl configuration engine in the sections. This gives us the > > ease of the second example with the programming simplicity of the first (i.e., > > no new functions). > > I actually like this alot. My question would be how to parse something > that didn't have one element, or that had multiple ones, for example I > can envision: > > > > > The first one exists, while the second one is (as far as I'm aware) only > theoretical. However, should they be solved as: > > $conf->{perl}->{somesetting} > $conf->{somecontext}->{'/a'}->{'/b'}->{somesetting} Not sure about the 'multi' context version. It's ugly though and I hope it doesn't happen. However, for the 'no context' version, I suggest: foo(); bar(); The you could have either: $conf->{perl} returns foo(); bar(); or ["foo();\n", "bar();\n"]; I *think* I prefer the latter. -- Piers BEGIN {$^H {integer} = sub {chr shift}; $^H=33<<12} print 74,117,115,116,32,97,110,111,116,104,101,114; print 32,80,101,114,108,32,72,97,99,107,101,114,10;
Re: Apache::Config module
James- > You might want to reconsider the usecanonicalname setting. The hash element > should exist if and only if it appears in the configuration file. It should > be defined if and only if it has an argument in the configuration file. > > Thus, the following results: > > UseCanonicalName > results in $conf->{usecanonicalname} == undef > > UseCanonicalName Off > results in $conf->{usecanonicalname} == 0 > > Then use existance in the hash array to test existance in the configuration > file. You may have already been thinking along this line. If so, then I'm > only clarifying a point... You're exactly right - that's why I make a distinction between 0, 1, and undef, so: UseCanonicalName On# = 1 UseCanonicalName Off # = 0 #UseCanonicalName On# = undef (commented out) That way, the logic in your script/module/whatever can set a default value: if ( ! defined($conf->{usecanonicalname}) ) { # not specified, set default(s) } elsif ( ! $conf->{usecanonicalname} ) { # explicitly turned off } else { # explicitly turned on } This lets you default to any value you want (on or off). Does this help clarify? Regarding this: > Perhaps > > 3. multi-level hash, i.e. >$conf->{directory}->{'/'}->{sethandler} > > This is, afaik, more in-line with what the ... sections do. I > would suggest making it so the output of this module could easily be fed into > the mod_perl configuration engine in the sections. This gives us the > ease of the second example with the programming simplicity of the first (i.e., > no new functions). I actually like this alot. My question would be how to parse something that didn't have one element, or that had multiple ones, for example I can envision: The first one exists, while the second one is (as far as I'm aware) only theoretical. However, should they be solved as: $conf->{perl}->{somesetting} $conf->{somecontext}->{'/a'}->{'/b'}->{somesetting} Input??? I just want to plan this out from the start so that as things are added later the syntax and/or structures don't get unwieldy. I don't want to change the "API" to such a module once it's out there. Thanks again for the feedback. -Nate
Re: Apache::Config module
Nathan Wiger <[EMAIL PROTECTED]> wrote: >Hi all- > >I've written a module that can parse the Apache httpd.conf config file >(and in fact any Apache-like config file). It will take a set of >directive like: > > ServerName www.mydomain.com > UseCanonicalName Off > >And parse it case-insensitively, returning a ref to a hash: > >my $ac = new Apache::Config; >my $conf = $ac->readconf($configfile); >print $conf->{servername}; # = "www.mydomain.com"; >print $conf->{usecanonicalname}; # = 0 (not undef so can test > #for defined() still) > Sorry for two posts... thought about this right after sending the first... You might want to reconsider the usecanonicalname setting. The hash element should exist if and only if it appears in the configuration file. It should be defined if and only if it has an argument in the configuration file. Thus, the following results: UseCanonicalName results in $conf->{usecanonicalname} == undef UseCanonicalName Off results in $conf->{usecanonicalname} == 0 Then use existance in the hash array to test existance in the configuration file. You may have already been thinking along this line. If so, then I'm only clarifying a point... -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Re: Apache::Config module
Nathan Wiger <[EMAIL PROTECTED]> wrote: >Hi all- > >I've written a module that can parse the Apache httpd.conf config file >(and in fact any Apache-like config file). It will take a set of >directive like: [snip] >I am also finishing up the ability to parse within contexts, such as > and . I am still unsure of the interface, I have >two ideas: > >1. multi-level hash, i.e. > $conf->{"directory /"}->{sethandler} > >2. individual functions, i.e. > $conf->directory("/")->{sethandler} Perhaps 3. multi-level hash, i.e. $conf->{directory}->{'/'}->{sethandler} This is, afaik, more in-line with what the ... sections do. I would suggest making it so the output of this module could easily be fed into the mod_perl configuration engine in the sections. This gives us the ease of the second example with the programming simplicity of the first (i.e., no new functions). We can also pull out the information we might want: I can get a list of all the directories I'm configuring with the first or third method, but the first is messy. The second method doesn't give us an obvious solution to this. Even though I would not suggest configuring Apache by reading in a configuration file and feeding it to the mod_perl engine, it does have a certain aesthetic appeal to me... besides, I only have to learn one way of thinking about it :) -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Apache::Config module
Hi all- I've written a module that can parse the Apache httpd.conf config file (and in fact any Apache-like config file). It will take a set of directive like: ServerName www.mydomain.com UseCanonicalName Off And parse it case-insensitively, returning a ref to a hash: my $ac = new Apache::Config; my $conf = $ac->readconf($configfile); print $conf->{servername}; # = "www.mydomain.com"; print $conf->{usecanonicalname}; # = 0 (not undef so can test #for defined() still) I am also finishing up the ability to parse within contexts, such as and . I am still unsure of the interface, I have two ideas: 1. multi-level hash, i.e. $conf->{"directory /"}->{sethandler} 2. individual functions, i.e. $conf->directory("/")->{sethandler} If anyone has any input, I'm all ears. Right now I'm leaning towards the second one, if I can get it working. The first one is really flexible and easy, the problem is that it's difficult to search. The second one helps with this issue, but the downside is that new functions have to be added if new Apache contexts are defined. I'm trying to play some tricks with the AutoLoader ala Shell to get new functions defined on the fly. If anyone has good ideas for a better interface, I'd also like to hear them. In any case, I have several questions: 1. Does a module like this exist anywhere? I saw Doug's Apache::httpd_conf, but this only takes care of writing a very minimal config file. I looked thru all the Apache:: modules but didn't see one. 2. Is the name Apache::Config a good name for this module? It seems like the obvious choice to me, and doesn't look like it's taken. I've also played around with Apache::ConfigFile and Apache::ReadConf, either of which I'm open to as well (or other suggestions?). I'm aware of the Apache and Apache::Constants modules, which do provide Apache API methods for getting to this data that work great for mod_perl. My goal with this module was to make it general enough to be used to parse any Apache-style config file. That way, if you wanted (a) write a CGI script outside of mod_perl that used httpd.conf data, or (b) wrote a custom (maybe non-web) app that used an Apache-like config file, you could get at the data quickly. In this way it would be like Apache::Session, where it can work either in a CGI or mod_perl context. Thanks for your help and input. -Nate