On Thursday 18 November 2004 12:16 pm, Garrett Goebel wrote: > I sat in at a number of mod_perl sessions at ApacheCon this past week. > According to Geoffrey Young and Phillipe Chaisson mod_perl 2.0 has no > pending feature additions, and only 6 or 7 outstanding bugs to resolve. > Geoffrey would only say "Real soon now", but Phillipe gave a "before year > end" estimate on when mod_perl would be released. > > If you know of bugs or difficiencies now would be the time to share them... > ;-)
Well, I'd basically have to run CVS mod_perl 1.99_xx I would guess in order to give good feedback. Definitely in the latest released developer version the state of the thing SEEMS a lot less polished than these guys are saying. A goodly number of documented functions don't exist and I ran into a whole running battle with Apache::RequestRec and APR::Table hurling segfaults when you did things that manipulated the parameters tables and whatnot. It IS useable in that generally you can find SOME way to do what you want, its just a lot of the documented ways crash, so its more annoyance level with version _17 than anything else. > > > 2) The most rough part is config, which is one thing AxKit always > > did really nicely, so it looks like to build in configuration > > capabilities equivalent to AxKit 1.6 has on 2.x Apache is still > > not possible as of 1.99_17, at least not in perl. > > Perhaps I'm missing something, but building configuration directives for > Perl modules in mod_perl 2.0 looked really really easy. Check out Geoffrey > Young's "mod_perl 2.0 at warp speed" slides 13+ at: > http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2004/mp2-warp.pdf Yes, it IS very easy, its just riddled with unimplemented functions! I still haven't found a version which lets you push a new directive dynamically into the configuration, its just not there! Again, a lot of it works, a bunch of it doesn't... Maybe in CVS the situation is different. > > Or the Apache Server Configuration Customization in Perl docs at: > http://perl.apache.org/docs/2.0/user/config/custom.html > > Or for a short example: > package My::Directive; > use Apache::Module (); > use Apache::Const -compile => qw(FLAG RSRC_CONF); > use Apache::RequestRec (); > use Apache::ServerRec (); > my @directives = ({ name => 'Widget', > req_override => Apache::RSRC_CONF, > args_how => Apache::FLAG }); > Apache::Module::add(__PACKAGE__, [EMAIL PROTECTED]); > sub Widget { > my ($cfg, $parms, $arg) = @_; > $cfg->{widget} = $arg; > } > sub handler { > my $r = shift; > my $cfg = Apache::Module::get_config(__PACKAGE__, > $r->server, > $r->per_dir_config); > my $widget = $cfg->{widget}; > ... > } As I said, I know HOW its SUPPOSED to work. The basic framework of configuration does work (well with again a bug or two but nothing too tragic). Just some features that I would need aren't there yet. Its not a show stopper, just requires some ugly hacks in httpd.conf for now. > > > Currently It uses the streaming filter interface, but I THINK if > > I understand bucket brigades correctly you SHOULD be able to chain > > several of these together and brigade the DOM from one to the next > > without serializing. Or if that isn't possible then I guess there's > > always 'pnotes' :). That would increase efficiency greatly in > > real-world scenarios. > > The documentation I've seen on bucket brigades is all in the context of > input and output filters operating on a individual chunks (buckets) in the > stream of data (brigades). My reading of the docs on brigades indicates that a bucket can contain references to data structures. I'm just not really sure about how you can effectively use that. For example putting a ref to a LibXML DOM in a bucket might let you pass it on down to a downstream perl based Filter, but you can't ever know if there IS such a filter, or at least you'd have to do some poking around to find out. Its an 'area for further research' :). Overall Its certainly possible to build a tool on mod_perl 2. Its maybe going to have some workarounds for a while, but thats OK. I'll be happy to post the code I have, its pretty crude, but it works! > > -- > Garrett Goebel > IS Development Specialist > > ScriptPro Direct: 913.403.5261 > 5828 Reeds Road Main: 913.384.1008 > Mission, KS 66202 Fax: 913.384.2180 > www.scriptpro.com garrett at scriptpro dot com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
