On Thu, 2003-06-12 at 02:59, Marc M. Adkins wrote: > > > The code to implement blocks (e.g. <TIPool>...</TIPool>) in > > config files is > > > pretty gnarly, too. I know it's already there for <Perl>, it's > > one of the > > > places I looked when I was considering doing one of my own and > > wanted to see > > > an example. The Apache framework is pretty strong for putting in new > > > directives, but not so much for adding new blocks. > > > > Actually you can't quite do that in a 3rd party module. Currently > > the pools > > are internal to mod_perl. Making this customizable will require > > adding hooks > > to the internal tipool mechanism. When I wrote the above > > pseudo-config I was > > suggesting an internal support for these. > > I was actually not figuring to do it myself. ;) > > I was commenting on the code required to implement things like <Perl> or > <TIPool>. I've since queried the httpd-dev list and the 'official' example > is in the source for mod_proxy (with a caveat that a three-pass config file > parser may necessitate further changes at some point). It appears to be a > lot simpler than the parsing that mod_perl is doing. I was wondering...is > there a specific reason mod_perl implements <Perl> the way it does or is it > just code inertia?
With something like a <Proxy http://foo/*></Proxy> block, mod_proxy does the right thing ( and the simple ) of using the power of ap_walk_config() to handler the parsing of the contents of the block. You might want to do the same thing for something like <TiPool>, allowing things like <Server> MaxTiPoolConn 10 <TiPoll special> MaxTiPoolConn 20 </TiPool> And have each directive in the <TiPool> block be handled like regular apache directive with all the cool benefits of configuration merging, etc. Reason <Perl> blocks can't do that is becasue we can't let httpd try and parse perl code and make any sense of it. If you look closely, a <Perl> block simply slurps all its contents and feeds it to perl for processing. Hope this makes sense. > mma -- -------------------------------------------------------------------------------- Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B) http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5 Q: It is impossible to make anything foolproof because fools are so ingenious. perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
