I don't really see the utility of this thread, since these are just circular arguments based primarily on opinion, and no one is going to convince someone else that their opinion is wrong.
That said, I'll just point out one thing about the earlier comment "How many platforms can survive 30 years. Mod_Perl/Apache." Mod_perl is 24 years old (http://perl.apache.org/about/history.html), Apache httpd is 25 years old (https://httpd.apache.org/ABOUT_APACHE.html), and Perl is roughly 32 years old (https://en.wikipedia.org/wiki/Perl). At this point, no Mod_Perl/Apache platforms has survived 30 years. I have 1 Mod_Perl/Apache platform left and it is about 9 years old, and its lifespan is currently based on inertia. At some point, it will be replaced by a new system written in a programming language for which the system owner (ie not me) can shop around, unless the dollar cost of doing that is greater than letting inertia continue. One other comment. The worst performing parts of my Mod_perl/Apache application have nothing to do with Mod_perl or Apache. They have to do with poor quality code and poor database schema design completed by other developers nearly a decade ago. I could run the same application using Starman and Nginx, and it would still have the exact same problems. You can take any tool and craft a poor solution. Likewise, you can take many tools and craft a great solution. I have no complaints about Mod_perl/Apache per se, but - like Perl - they're aging. I already use Starman with other projects, and at some point I'll replace mod_perl with it, as I know it better and I know more people who know it better. I'm also using a Catalyst framework, so it's pretty much plug and play. Note also that it's easier to get a specific version of Starman than it is to get a specific version of Mod_perl/Apache in a particular OS. Anyway, with the exception of those aforementioned dates, that's just my opinion. David Cook -----Original Message----- From: Ruben Safir <ru...@mrbrklyn.com> Sent: Wednesday, 5 August 2020 5:14 AM To: André Warnier (tomcat/perl) <a...@ice-sa.com> Cc: modperl@perl.apache.org Subject: Re: suggestions for perl as web development language [EXT] On Tue, Aug 04, 2020 at 05:04:50PM +0200, André Warnier (tomcat/perl) wrote: > On 04.08.2020 11:31, paul trader wrote: > >On Tue, 4 Aug 2020 at 07:36, James Smith opined: > > > >JS:Others will disagree but the best way I still believe is using > >mod_perl > >JS:- but only if you use it's full power - and you probably need a > >special JS:sort of mind set to use - but that can be said for any language. > > > >i will second this motion. mod_perls ability to hook into any step > >of the process apache uses to serve up a page makes it easy to design > >a web solution that can be tailored for any solution. > > > > Let me agree and add to that. > > If your purpose is simply to write "classic web applications" (in the > sense of user interface etc), then there are probably nowadays easier > and "more modern" tools than mod_perl; and indeed it is a problem to > find young programmers who already know perl. > (It is not difficult however for a good young programmer, to learn > perl. And I would always prefer a good young programmer who doesn't > know perl yet, over a not so good young programmer who knows > everything except perl.) > > On the other hand, if your kind of project involves a very tight > integration with all aspects of Apache httpd, then there really isn't > any other tool than mod_perl to do it. > It is difficult in a short message like this to detail all the ways > that you can interact with Apache httpd to get things done, but have a > look at the schema here : > > https://www.askapache.com/s/s.askapache.net/httpd/modules/modsecurity- > apache_2.1.4/doc/html-multipage/04-processing-phases.html > > and imagine that, with mod_perl, you can interact with Apache httpd > and control virtually everything that happens within any of those > boxes (and even between them). > Together, Apache httpd + mod_perl are a tool for creating complex > web-based applications, which has no equivalent anywhere (not with any > other webserver, not with any other programming language, not with any > kind of OS)(in the open-source/free world). > In addition, using mod_perl does not prevent you from using any other > Apache add-on module or any other development tool in addition (in > whatever programming language you choose). mod_perl just allows you to > do more, and faster. > > A possible problem with mod_perl may be its continued support, > considering the kind of discussions (hopefully temporary) going on at > the moment in the perl 5.x/7.x development community. > But I believe that there is such a wide existing base of solid web > applications based on perl, mod_perl and the (also incomparable) CPAN > library, that any idea of dropping support for them, would be for some > time quite far in the future. > Everything depends.... Consider this though, when whipping up your new JSOm superwidget dodad enterprise project... How many platforms can survive 30 years. Mod_Perl/Apache. How many platforms can be taken seriously with regard to privacy? If I am doing a serious enterprise for something like healthcare, you need to consider mod_perl for the longevity and security. Concurancy is a problem that the modperl team and perl team should fix. > P.S. As an example : I am at the moment working on expanding an > Apache/mod_perl user authentication module, that has to be able to > authenticate users using either of HTTP Basic, LDAP, SAML, SPNEGO > (Windows), OpenId, SiteMinder (tm), client IP and and login-form based > authentication, while delivering a consistent "user profile" > to follow-up web applications. > And I cannot think of any other tool than Apache/mod_perl which would allow me to do this. > (except this : https://metacpan.org/pod/Apache2::AuthAny, but that is > also mod_perl based) -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
signature.asc
Description: PGP signature
