Jesse, > The first case (which you reference in your message) can be factored out > entirely using mod_perl. By adding a simple "startup.pl", CGI.pm can be > pre-compiled on server start. If your issue is limited to compile-time > performance, using mod_perl will eliminate this as a significant factor.
A most excellent point! Using mod_perl would definitely alleviate the startup time costs. However, there is also the size factor, and this is particularly a big issue under mod_perl, since all modules will stay compiled and cached within each Apache process. Many will still choose to use CGI.pm under mod_perl, because it's the right module for them. However, as the following document within the mod_perl guide points out: http://perl.apache.org/guide/performance.html#_Bloatware_modules Loading Apache::Request adds around 48K to the size of each httpd process. However, adding CGI (with everything compiled) takes up 1.8MB. Eek! On top of that, much of Apache::Request is written in C, so there may definitely be some performance differences involved. As an example: http://perl.apache.org/guide/performance.html#Apache_args_vs_Apache_Request The mod_perl guide offers some benchmarks on a few modules, and they all turned out to be at least twice as fast as CGI when running under mod_perl. Knowing that, even though CGI.pm offers some wonderful functionality, many mod_perl users try to stay away it. > Once you eliminate technical considerations, such as compile-time > performance, there are (IMHO) some compelling reasons to use CGI.pm. I agree whole-heartedly! CGI.pm offers an incredible amount of useful features. However, I don't feel that I'm necessarily saying, "Lets get rid of CGI from the picture". The OpenPlugin Plugin Manager that I'm building actually offers a CGI driver, allowing one to take full advantage of CGI if they choose. At the same time though -- OpenPlugin would allow them to switch out the CGI driver, for the Apache::Request driver, at any time. OpenPlugin just offers a standard interface for CGI and Apache::Request (amongst other things). But, to be able to use OpenPlugin within CGI::Application -- even if we're looking to use the CGI module -- CGI::Application would need to use OpenPlugin's interface, in order to be capable later of changing drivers. I am aware that there are a certain amount of issues that would be encountered with an approach offering a choice in this matter. I've been tinkering around with the code in CGI::Application, just to see what it would entail to produce what it is I'm hoping to able to utilize. One particular difference is that we'd lose the benefit of loading CGI at compile time, instead of runtime. I'm not sure how big a deal this would be to folks. To fully be able to make use of "factoring out CGI.pm", there are also some design philosophy issues that may be encountered, although many of these can end up being optional. 1. With the combination of modules that I'm putting together, I've seen a desire in many to actually make CGI::Application capable of having a parent class, which may be CGI, OpenPlugin, or whoever. While useful, it also makes me scratch my head -- would this break any OO design ideals? 2. Given #1 above, that breaks CGI::Application's 'param' method (as CGI, Apache::Request, and OpenThought have param methods).. if allowing CGI::Application to have a parent class is desired, then perhaps the name of the param method needs to be an option. 3. There are times when one may need to output data to the browser, at several points throughout the life of a CGI/mod_perl app. What if we're about to do a long database query? For this, maybe we'd want to output occasional status messages. CGI::Application currently offers an excellent mechanism for keeping code clean, by having you return, as a string, the HTML you want delivered to the browser. In a case where this behaviour may not be desired though, what are the thoughts on being able to return undef, instead of HTML. Perhaps undef could signal CGI::Application that headers and HTML have already been sent. These are all some thoughts. I'm most curious to hear what everyone has to say on the matter. Are features like this something people want out of CGI::Application? Would what I'm suggesting be better off implemented in a new module? I'm also willing to put my code where my mouth is -- I'd be more then happy to assist with any of the above :-) Thanks for your time, -Eric --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
