I go back and forth on this issue. while Registry comes close to emulating mod_cgi, the point I waver on is whether we really should bill it as a drop-in replacement
That is how people try to use it. The less they have to change their code, the better.
what's the real goal with registry - to provide 100% compat with mod_cgi or to make mod_cgi-like scripts run as fast as they can?
I think definitely the former. People who are really concerned about performance should not be using Registry.
the reason I suggested a subclass was so that the rare people who require nph scripts have an outlet, while the vast majority of users are not burdened with the overhead of checking for nph- scripts on every request.
A quick index() call to check for "nph-" is not going to matter in any real world scenario.
mod_perl doesn't send headers anymore - the header filter in apache 2 core does that now. there is no $r->send_http_header() method.
So does the header filter send out heaers if I don't ask it to?
one I do feel strongly about. however insane it is to have a public assbackwards() API, mod_perl should just be offering up the Apache API as it is and getting out of the way. that's what it's called in the Apache API, so $r->assbackwards needs to stay.
You're right, mod_perl is not the place to fix this. I should be compaining to the core apache team about it if I want it changed. It's just a shame because this was obviously meant to be used internally only and now it's a confusing and amateurish part of the public API.
- Perrin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
