I received this message from a fellow who is interested in using CGI::Application within his company's home-grown application architecture. With Eric's permission I am forwarding him message to the list for comment. (My reply will follow.)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 3:39 PM To: [EMAIL PROTECTED] Subject: CGI::Application Howdy, I have some interesting thoughts and suggestions regarding CGI::Application, but I first need to give you some quick background information. I'm the author of a Perl-based application framework called OpenThought (http://openthought.net). It is unique in many ways. I've tried to keep it small and "to the point", so that it can make use of other modules that already exist, so that I don't have to recreate what already exists. Just typical reuse of software... OpenThought shares certain requirements with other application frameworks such as Session support, Authentication, Error Handling, etc. Instead of recreating all of that and hard coding it into OpenThought, I actually began a new project called OpenPlugin which incorporatates all of that functionality into Plugins. Each Plugin can have any number of drivers. For example, the Log Plugin can have drivers for STDERR, Syslog, and File. It also has a Param Plugin with drivers for both CGI and Apache (which use CGI.pm and Apache::Request, respectively). The external API for the Param plugin remains static, but you can switch out the CGI and Apache drivers at will. The same goes for the Headers, Upload, and Cookies plugins, which all have CGI and Apache drivers. OpenThought (the application framework) stays out of the way enough of run-time handling of requests that it's actually possible to use CGI::Application with it. However, there are a few areas of overlap that make it unfortunatly difficult to use CGI::Application. So, I was hoping to toss a few thoughts your way, to see how you felt :-) 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? It may even be possible to branch CGI::Application into, say, OpenPlugin::Application.. but that certainly isn't my first choice, as I don't want to take any credit for your most excellent module :-) I also wouldn't benefit from additions and bugfixes that you add.. but then, thats the disadvantage of forking. 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. Those two issues are the biggest things I need to overcome to make CGI::Application readily usable with OpenThought and OpenPlugin. Do you have any thoughts on this? Is this a big enough change, that you would prefer a fork of some kind? I look forward to your response! And if you have any questions, by all means, please feel free to ask. Thanks, -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]
