Elizabeth Mattijsen wrote: [...]
Most users don't need to know. I would like to supply my general purpose modules, which can run in a stand-alone script, under mod_perl 1 or mod_perl 2, with sensible default behaviour. So that you don't need to make changes to your config when you switch from prefork to threaded MPM's.
For example, CGI.pm provides the:
use CGI (-compile :all)
way to have everything loaded. Now, in my opinion, CGI.pm should do The Right Thing in a prefork MPM environment and make that behaviour the _default_. So you don't have to know about it as a developer.
Actually, it's not the perfect thing to do. You want to give developers a full control over how things are loaded. I don't want to precompile 'all:' most of the time, but just a small sub-set of the API. Of course you may argue that developers that are unaware of this feature, would be still better off with precompiling all methods even they aren't used. But here is an example, when this is incorrect - if you didn't load CGI.pm at the server startup. The it's a big waste to call -compile 'all' from the script. So developers need to know to preload CGI.pm at the startup, and if they do, chances are that they read the docs and will know that they need to -compile symbols they are goind to need. You may further argue that CGI.pm could figure out whether it's being loaded at the startup or not, and while I agree that it'd be cool, we don't have the functionality to do so yet. But the issue pops up every so often and I think we will add this functionality some time in the future (i.e. being able to tell which phase you are in).
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
