On Tue, 8 Jun 2004, Geoffrey Young wrote: > well, I think it really depends on what you want to accomplish. all the > above really seems like just a perl versus php (or $web_language) debate: > both run on a number of different server platforms, have strong followings, > and are proven scalable and "enterprise" (sorry for throwing out that term, > but you get the idea :). in the end, arguments like the above are very, > very important ones for us as perl programmers, but I don't think they help > mod_perl prosper as a technology, which is what I'm interested in :) > > while I realize I'm in the minority with this view (and perrin and I have > had this discussion/friendly disagreement before :) what _I_ like about > mod_perl cannot be satisfied by anything other than mod_perl - I like the > Apache API, and I would prefer to use it in conjunction with Perl rather > than mess around with C (or even something like apache_hooks, since I don't > know php :) for those that share a love for this particular aspect of > mod_perl and have a desire to see it prosper, nothing else will really do.
I agree with Geoff on both points above, but in my experience the things that are obvious and important to us as mod_perl programmers are not necessarily the primary considerations for choosing a platform when a project is ramping up (even if they should be). Designs are not always well thought out, and future development of projects can't always be predicted, so sometimes it might only be in hindsight that you realize that you have a need that could have easily been satisfied by the power/flexibility of mod_perl but not necessarily by the platform you chose (assuming you didn't choose mod_perl in the first place...). What I have seen is people initially choosing a platform because it quickly meets the needs of a prototype or proof of concept, and then that chosen platform ends up being what's released in production. When you want to get a proof of concept up and running quickly, you might tend to look for systems where it's quick and easy to implement common infrastructure tasks like: managing user sessions, managing database connections, handling config files, and logging. This lets you concentrate on your application code, which is the interesting part. For example, I've spoken with people who said they chose PHP or ASP for the initial implementation of a project specifically because they thought it looked like it would be easy to handle sessions and/or do database coding, and they assumed it would be sufficient for the rest of the application stuff they needed to do. We mod_perl people know there are (many) straightforward solutions for those kind of infrastructure things, e.g. Apache::Session::*, Apache::DBI, Config::IniFiles, and Log4Perl, respectively. But I don't think it's obvious at all to newbies or outsiders that those kind of things are available or easily implemented. So getting back to an idea that appeared early in the thread, it would probably be good to have something like a centralized, well-documented "toolkit" of code/modules/patterns (not sure the best form that would take) that could be quickly hooked together into a skeleton application. I know all the pieces are out there, maybe it's just a matter of figuring out the best presentation... Larry -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
