> However, if that still seems like too long, and your code is too > tricky for Apache2::Reload, there are two simple solutions. One is to > develop under CGI, which should be easy for most CGI::App users. Then > you just switch over to mod_perl when you're ready for testing.
I think I'll do this one. That's definitely reasonable. What about the dispatch stuff? Will my URL just look like this: foo/Dispatch.pm/controller_foo/action ? > Another is to set MaxRequestsPerChild to 1, so that your code is > compiled fresh every time. If you do this, make sure you don't load > the code you're editing in your startup.pl (before the fork). I'd prefer to do the previous idea as I've had lots of success with apache and vanilla cgi before, but I may look into this when I'm not so busy. >> I also like the idea that with FastCGI we can switch back to IIS. > > Can't say I agree with you there, but to each their own. However, I > would caution you that when I tried to find an IIS FastCGI solution a > few years ago, there was really nothing available. That may have > changed since Ruby increased the popularity of FastCGI. Well, technically I agree with you and I think we should abandon IIS and SQL Server and Windows even, but you have to start small :-) I think I'll just do the CGI stuff for now as that should be just fine really. mod_perl may be overkill anyway as we will probably never have more than 5 users at the same time as this app is for one single small organization. -fREW ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################