Hi Eric -- > 1. When using the OpenPlugin plugin manager, it doesn't > matter whether one uses > CGI or mod_perl. However, mod_perl users often don't want > the overhead of > loading CGI.pm, if they'll only be using Apache::Request > under mod_perl. > However, it seems as if CGI.pm is a requirement for using > CGI::Application. > > Do you have any thoughts as to making the use of CGI.pm > optional? Or, to > perhaps even make the module used for handling such requests a runtime > parameter, where things such as even OpenPlugin could be used > as a replacement? > > 2. A similar problem as with #1, OpenPlugin has it's own > header handling > plugin, which abstracts CGI.pm. It's different enought that > the two can't > really work together very well. > > This again may be handleable with a run-time parameter > telling CGI::Application > what module to use for headers. >
This has come up in discussion before. The short answer is, CGI::Application is tightly bound to CGI.pm. To decouple the two may be possible, but such an architectural change had not been envisioned when the module was created. That said, CGI::Application internals only use CGI.pm in a couple specific places. It might be possible to encapsulate those points and allow custom sub-classes to override this functionality. Let me ask you a different question, however -- I have found that there are two primary reasons people don't want to use CGI.pm: 1. Compile-time performance. CGI.pm takes an amazing amount of time to compile to byte-code. 2. Personal preference. Some developers feel very proprietary about their "CGI.pm-replacement" module, and just prefer their way instead of CGI.pm's way. 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. Regarding personal preference: As you probably know, there is no rational argument which can be made to convince a developer that their way may not be as good as some other way. (Try to convince me to use something besides CGI-App and HTML-Template some day! :-) Once you eliminate technical considerations, such as compile-time performance, there are (IMHO) some compelling reasons to use CGI.pm. For starters, CGI.pm is battle-tested. After, literally, dozens of releases it has been pretty thoroughly scrubbed free of security issues, portability issues and bugs. Second, it is feature-rich. It supports HTTP uploads and a dozen other features which are non-trivial to implement (let alone, to implement without bugs! See point one). Finally, it is well-known! Developers everywhere understand how to use it. Any home-grown replacement could only endeavor to emulate its interface -- and that, in itself, is a compelling endorsement of CGI.pm. If, after considering my arguments (or brushing them aside, as the case may be :-), you are still of the mind to want to replace CGI.pm I will take another look at the CGI::Application implementation and see if there is a reasonable way to encapsulate its use. Warmest regards, -Jesse- Jesse Erlbaum, CTO Vanguard Media http://www.vm.com 212.242.5317 x115 [EMAIL PROTECTED] --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
