Mailing List Archive

I think all languages have lost the battle to nodejs. Most popular
frameworks are angular and react - it is hard to beat them when everyone
seems to be able to throw out a single page application without much effort.

On Tue, Aug 4, 2020, 12:43 AM Wesley Peng <me@yonghua.org> wrote:

> greetings,
>
> My team use all of perl, ruby, python for scripting stuff.
> perl is stronger for system admin tasks, and data analysis etc.
> But for web development, it seems to be not as popular as others.
> It has less selective frameworks, and even we can't get the right people
> to do the webdev job with perl.
> Do you think in today we will give up perl/modperl as web development
> language, and choose the alternatives instead?
>
> Thanks & Regards
>
>

I would not consider mod_perl for new projects, but instead highly recommend using mojolicious https://mojolicious.org/ <https://mojolicious.org/>


> Am 04.08.2020 um 07:42 schrieb Wesley Peng <me@yonghua.org>:
>
> greetings,
>
> My team use all of perl, ruby, python for scripting stuff.
> perl is stronger for system admin tasks, and data analysis etc.
> But for web development, it seems to be not as popular as others.
> It has less selective frameworks, and even we can't get the right people to do the webdev job with perl.
> Do you think in today we will give up perl/modperl as web development language, and choose the alternatives instead?
>
> Thanks & Regards
>

Rolf Schaufelberger

What about dancer?

On Tue, 4 Aug 2020, 12:10 Rolf Schaufelberger, <rs@plusw.de> wrote:

> I would not consider mod_perl for new projects, but instead highly
> recommend using mojolicious https://mojolicious.org/
>
>
> Am 04.08.2020 um 07:42 schrieb Wesley Peng <me@yonghua.org>:
>
> greetings,
>
> My team use all of perl, ruby, python for scripting stuff.
> perl is stronger for system admin tasks, and data analysis etc.
> But for web development, it seems to be not as popular as others.
> It has less selective frameworks, and even we can't get the right people
> to do the webdev job with perl.
> Do you think in today we will give up perl/modperl as web development
> language, and choose the alternatives instead?
>
> Thanks & Regards
>
>
> Rolf Schaufelberger
>
>
>

Perl is a great solution for web development.

Others will disagree but the best way I still believe is using mod_perl - but only if you use it's full power - and you probably need a special sort of mind set to use - but that can be said for any language.

From experience - it may be fractionally slower than small "standalone" apps that dancer etc are good at, but it is (a) much, much more stable {dancer etc does not cope well with either large requests or lots of small requests}, and (b) if you have a large code base and/or a large number of services then it generally uses much less compute power than the others {can easily handle multiple services on a single apache instance}

Where it really gains is the hooks into the apache process - being able to add functionality easily at any stage in the request process, from path translation, AAA stages, pre-processing, to post-processing and logging, and also to interact with other languages at any stage - e.g. can handle pre-processing & post-processing around a script written in another language (e.g. PHP, Java) or produced by another webserver integrated by mod_proxy.

It isn't really a framework though like dancer or mojolicious and thus has its own advantages and disadvantages.

You would to some extent have to roll your own code to produce the pages themselves although there are libraries out there to do lots of it.

We have an in house library whose embryonic stages were written over 20 years ago - and has now been stable for around 12-13 years and works strong...

James

-----Original Message-----
From: Wesley Peng <me@yonghua.org>
Sent: 04 August 2020 06:43
To: modperl@perl.apache.org
Subject: suggestions for perl as web development language [EXT]

greetings,

My team use all of perl, ruby, python for scripting stuff.
perl is stronger for system admin tasks, and data analysis etc.
But for web development, it seems to be not as popular as others.
It has less selective frameworks, and even we can't get the right people to do the webdev job with perl.
Do you think in today we will give up perl/modperl as web development language, and choose the alternatives instead?

Thanks & Regards




--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

Hello,

James Smith wrote:
: Perl is a great solution for web development.
:
: Others will disagree but the best way I still believe is using mod_perl
: - but only if you use it's full power - and you probably need a special
: sort of mind set to use - but that can be said for any language.

Agreed. We have a codebase spanning 20 years, 2.3M LoC (without
comments). Some of it even pre-dates mod_perl (written originally for CGI.pm),
but mostly it uses code based on RegistryCooker as its underlying
infrastructure.

I just don't see a clean path towards HTTP/3 QUIC multi-session
connections in mod_perl. Sure, a reverse proxy will do, but it might be
better to do it natively. Do you know about any development of Apache+mod_perl
related to HTTP/2 or HTTP/3?

-Yenya

--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| http://www.fi.muni.cz/~kas/ GPG: 4096R/A45477D5 |
IORING_OP_NOP ... the benefits of doing nothing asynchronously are minimal,
but sometimes a placeholder is useful. --Jonathan Corbet at LWN

Hi all,

we also have a big code base whose starting point is more than two decades ago.
If you have developers who know their stuff and all the internal developed modules
and helpers you're good to go. BUT: We do have problems to get young, fresh
perl developers. Why? This language is simply unattractive to young people.

If I had to start a web application today on an empty field I wouldn't choose perl.

There is another point. When we started all logic was done in the backend.
Nowadays much is done in the browser itself with Javascript. You need this
Javascript knowhow in any case. And when you have it there is no big step
to using this in the backend too.

So, in my opinion there is a relevant difference between starting a project
or maintaining an (very) old one. Maintaining an old code base where you're
stuck to years of old code is not attractive to new developers in any case.

mod_perl? The opinions may vary. But we're trying to get rid of it. In the
old days mod_perl with apache was the one and only process doing
everything. Now it's common to have serveral tiers. In the front a
load balancer which probably also terminates SSL. Some lightweight
servers serving static stuff as fast as possible, and one or more servers which
act as application server. As soon as several stages of request processing
are not done in Apache (e.g. Rewriting, Dispatching, Logging) you only
use one stage of Apache to produce the content. And this can be done
with a native perl application server.

Don't understand me wrong. We program in Perl, we know Perl more or less,
we have a big code base in Perl. But I won't start a new project on an empty (!)
field with it. But our field is NOT empty because we have so many known own
libraries and modules for all the common cross application requirements that
it would last very long to build these in a different language.

At the end you need people to do it. And you have to see how much legacy
code base and knowledge is there.

Regards
Andreas

-----Ursprüngliche Nachricht-----
Von: James Smith <js5@sanger.ac.uk>
Gesendet: Dienstag, 4. August 2020 09:37
An: Wesley Peng <me@yonghua.org>; modperl@perl.apache.org
Betreff: RE: suggestions for perl as web development language [EXT]

Perl is a great solution for web development.

Others will disagree but the best way I still believe is using mod_perl - but only if you use it's full power - and you probably need a special sort of mind set to use - but that can be said for any language.

From experience - it may be fractionally slower than small "standalone" apps that dancer etc are good at, but it is (a) much, much more stable {dancer etc does not cope well with either large requests or lots of small requests}, and (b) if you have a large code base and/or a large number of services then it generally uses much less compute power than the others {can easily handle multiple services on a single apache instance}

Where it really gains is the hooks into the apache process - being able to add functionality easily at any stage in the request process, from path translation, AAA stages, pre-processing, to post-processing and logging, and also to interact with other languages at any stage - e.g. can handle pre-processing & post-processing around a script written in another language (e.g. PHP, Java) or produced by another webserver integrated by mod_proxy.

It isn't really a framework though like dancer or mojolicious and thus has its own advantages and disadvantages.

You would to some extent have to roll your own code to produce the pages themselves although there are libraries out there to do lots of it.

We have an in house library whose embryonic stages were written over 20 years ago - and has now been stable for around 12-13 years and works strong...

James

-----Original Message-----
From: Wesley Peng <me@yonghua.org>
Sent: 04 August 2020 06:43
To: modperl@perl.apache.org
Subject: suggestions for perl as web development language [EXT]

greetings,

My team use all of perl, ruby, python for scripting stuff.
perl is stronger for system admin tasks, and data analysis etc.
But for web development, it seems to be not as popular as others.
It has less selective frameworks, and even we can't get the right people to do the webdev job with perl.
Do you think in today we will give up perl/modperl as web development language, and choose the alternatives instead?

Thanks & Regards




--
The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

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.

regards, paul

--
Paul Trader.....ptrader@igolinux.com
IGO Linux Solutions
'Linux for the rest of us'
http://www.igolinux.com

The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork
because very few perl dependencies are thread safe.
2) mod_perl cannot provide web sockets.

Due to these reasons, my organization has started looking at ways to move
away from mod_perl.

On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng <me@yonghua.org> wrote:

> greetings,
>
> My team use all of perl, ruby, python for scripting stuff.
> perl is stronger for system admin tasks, and data analysis etc.
> But for web development, it seems to be not as popular as others.
> It has less selective frameworks, and even we can't get the right people
> to do the webdev job with perl.
> Do you think in today we will give up perl/modperl as web development
> language, and choose the alternatives instead?
>
> Thanks & Regards
>
>

--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

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.

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)

From: John Dunlap <John@lariat.co>
Sent: 04 August 2020 15:30
To: Wesley Peng <me@yonghua.org>
Cc: mod_perl list <modperl@perl.apache.org>
Subject: Re: suggestions for perl as web development language [EXT]

The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
> 1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork because very few perl dependencies are thread safe.

Concurrency in extreme conditions - is actually better when it comes to mod_perl than a number of other solutions – e.g. nginx/starman. Apache/mod_perl is much better at handling large numbers of simultaneous requests than the systems which fork a number of small processes at start up to handle requests. You either have to fork a large number of these or pray you don’t get large numbers of simultaneous requests. Some of our systems have long return times for queries due to the terra/petabyte scale of some of our backend servers.

> 2) mod_perl cannot provide web sockets.

True – we haven’t really found an excuse for web-sockets although our front end “Application Delivery Controller” (which sits in the DMZ) can manage proxying requests that need sockets one way and others that don’t another way.
There are still a lot of issues with web-sockets – due to not all proxies handling these requests and so have to limit their use in a lot our cases [. a lot of our users are on networks that sit behind proxy/cache servers ]

> Due to these reasons, my organization has started looking at ways to move away from mod_perl.

We are using more off the shelf packages for some of our applications – e.g. Wordpress as a CMS/Object manager, and yes we are also moving to more front-end centric applications. But many of our fundamental pieces of code are still working in Apache/mod_perl as it is a better, more-reliable language to work with.


On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng <me@yonghua.org<mailto:me@yonghua.org>> wrote:
greetings,

My team use all of perl, ruby, python for scripting stuff.
perl is stronger for system admin tasks, and data analysis etc.
But for web development, it seems to be not as popular as others.
It has less selective frameworks, and even we can't get the right people
to do the webdev job with perl.
Do you think in today we will give up perl/modperl as web development
language, and choose the alternatives instead?

Thanks & Regards


--
John Dunlap
CTO | Lariat

Direct:
john@lariat.co<mailto:john@lariat.co>

Customer Service:
877.268.6667
support@lariat.co<mailto:support@lariat.co>
[cid:image001.png@01D66A7C.046364C0]



--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

My company uses Perl for web development. It handles real time payment
transactions without any problem. Good software is made by the people not
by the language.

Joseph

On Tue, Aug 4, 2020 at 10:28 AM James Smith <js5@sanger.ac.uk> wrote:

>
>
>
>
> *From:* John Dunlap <John@lariat.co>
> *Sent:* 04 August 2020 15:30
> *To:* Wesley Peng <me@yonghua.org>
> *Cc:* mod_perl list <modperl@perl.apache.org>
> *Subject:* Re: suggestions for perl as web development language [EXT]
>
>
>
> The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
>
> > 1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork
> because very few perl dependencies are thread safe.
>
>
>
> Concurrency in extreme conditions - is actually better when it comes to
> mod_perl than a number of other solutions – e.g. nginx/starman.
> Apache/mod_perl is much better at handling large numbers of simultaneous
> requests than the systems which fork a number of small processes at start
> up to handle requests. You either have to fork a large number of these or
> pray you don’t get large numbers of simultaneous requests. Some of our
> systems have long return times for queries due to the terra/petabyte scale
> of some of our backend servers.
>
>
>
> > 2) mod_perl cannot provide web sockets.
>
>
>
> True – we haven’t really found an excuse for web-sockets although our
> front end “Application Delivery Controller” (which sits in the DMZ) can
> manage proxying requests that need sockets one way and others that don’t
> another way.
>
> There are still a lot of issues with web-sockets – due to not all proxies
> handling these requests and so have to limit their use in a lot our cases [.
> a lot of our users are on networks that sit behind proxy/cache servers ]
>
>
>
> > Due to these reasons, my organization has started looking at ways to
> move away from mod_perl.
>
>
>
> We are using more off the shelf packages for some of our applications –
> e.g. Wordpress as a CMS/Object manager, and yes we are also moving to more
> front-end centric applications. But many of our fundamental pieces of code
> are still working in Apache/mod_perl as it is a better, more-reliable
> language to work with.
>
>
>
>
>
> On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng <me@yonghua.org> wrote:
>
> greetings,
>
> My team use all of perl, ruby, python for scripting stuff.
> perl is stronger for system admin tasks, and data analysis etc.
> But for web development, it seems to be not as popular as others.
> It has less selective frameworks, and even we can't get the right people
> to do the webdev job with perl.
> Do you think in today we will give up perl/modperl as web development
> language, and choose the alternatives instead?
>
> Thanks & Regards
>
>
>
> --
>
> John Dunlap
>
> CTO | Lariat
>
>
>
> *Direct:*
>
> john@lariat.co
>
>
> *Customer Service:*
>
> 877.268.6667
>
> support@lariat.co
>
> -- The Wellcome Sanger Institute is operated by Genome Research Limited, a
> charity registered in England with number 1021457 and a company registered
> in England with number 2742969, whose registered office is 215 Euston Road,
> London, NW1 2BE.
>

> On 4 Aug 2020, at 17:42, Joseph He <joseph.he.2008@gmail.com> wrote:
>
> My company uses Perl for web development. It handles real time payment transactions without any problem. Good software is made by the people not by the language.
>

Agreed, Perl is still fine for server-side work. mod_perl adds less value than it used to, though. You can get most of the benefits of mod_perl without the complexity. It’s only if you have to do really really unusual things in the request cycle where mod_perl helps a lot.

- Mark

And the point is it is getting very hard to find good perl programmers. It
is much easier to find python programmers who can get the job done.

On Tue, Aug 4, 2020 at 11:43 AM Joseph He <joseph.he.2008@gmail.com> wrote:

> My company uses Perl for web development. It handles real time payment
> transactions without any problem. Good software is made by the people not
> by the language.
>
> Joseph
>
> On Tue, Aug 4, 2020 at 10:28 AM James Smith <js5@sanger.ac.uk> wrote:
>
>>
>>
>>
>>
>> *From:* John Dunlap <John@lariat.co>
>> *Sent:* 04 August 2020 15:30
>> *To:* Wesley Peng <me@yonghua.org>
>> *Cc:* mod_perl list <modperl@perl.apache.org>
>> *Subject:* Re: suggestions for perl as web development language [EXT]
>>
>>
>>
>> The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
>>
>> > 1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork
>> because very few perl dependencies are thread safe.
>>
>>
>>
>> Concurrency in extreme conditions - is actually better when it comes to
>> mod_perl than a number of other solutions – e.g. nginx/starman.
>> Apache/mod_perl is much better at handling large numbers of simultaneous
>> requests than the systems which fork a number of small processes at start
>> up to handle requests. You either have to fork a large number of these or
>> pray you don’t get large numbers of simultaneous requests. Some of our
>> systems have long return times for queries due to the terra/petabyte scale
>> of some of our backend servers.
>>
>>
>>
>> > 2) mod_perl cannot provide web sockets.
>>
>>
>>
>> True – we haven’t really found an excuse for web-sockets although our
>> front end “Application Delivery Controller” (which sits in the DMZ) can
>> manage proxying requests that need sockets one way and others that don’t
>> another way.
>>
>> There are still a lot of issues with web-sockets – due to not all proxies
>> handling these requests and so have to limit their use in a lot our cases [.
>> a lot of our users are on networks that sit behind proxy/cache servers ]
>>
>>
>>
>> > Due to these reasons, my organization has started looking at ways to
>> move away from mod_perl.
>>
>>
>>
>> We are using more off the shelf packages for some of our applications –
>> e.g. Wordpress as a CMS/Object manager, and yes we are also moving to more
>> front-end centric applications. But many of our fundamental pieces of code
>> are still working in Apache/mod_perl as it is a better, more-reliable
>> language to work with.
>>
>>
>>
>>
>>
>> On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng <me@yonghua.org> wrote:
>>
>> greetings,
>>
>> My team use all of perl, ruby, python for scripting stuff.
>> perl is stronger for system admin tasks, and data analysis etc.
>> But for web development, it seems to be not as popular as others.
>> It has less selective frameworks, and even we can't get the right people
>> to do the webdev job with perl.
>> Do you think in today we will give up perl/modperl as web development
>> language, and choose the alternatives instead?
>>
>> Thanks & Regards
>>
>>
>>
>> --
>>
>> John Dunlap
>>
>> CTO | Lariat
>>
>>
>>
>> *Direct:*
>>
>> john@lariat.co
>>
>>
>> *Customer Service:*
>>
>> 877.268.6667
>>
>> support@lariat.co
>>
>> -- The Wellcome Sanger Institute is operated by Genome Research Limited,
>> a charity registered in England with number 1021457 and a company
>> registered in England with number 2742969, whose registered office is 215
>> Euston Road, London, NW1 2BE.
>>
>

mod_perl does have value because it does a more efficient utilization of
resources - this is important when fast response time and scalability is
important. The complexity is a known problem but it is not a mystery box
either - there is enough documentation which explains what has to happen
and what could have gone wrong.

On Tue, Aug 4, 2020 at 11:52 AM Mark Blackman <mark@blackmans.org> wrote:

>
>
> > On 4 Aug 2020, at 17:42, Joseph He <joseph.he.2008@gmail.com> wrote:
> >
> > My company uses Perl for web development. It handles real time payment
> transactions without any problem. Good software is made by the people not
> by the language.
> >
>
> Agreed, Perl is still fine for server-side work. mod_perl adds less value
> than it used to, though. You can get most of the benefits of mod_perl
> without the complexity. It’s only if you have to do really really unusual
> things in the request cycle where mod_perl helps a lot.
>
> - Mark

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

On Tue, Aug 04, 2020 at 11:42:34AM -0500, Joseph He wrote:
> My company uses Perl for web development. It handles real time payment
> transactions without any problem. Good software is made by the people not
> by the language.
>

Well, there is that...


> Joseph
>
> On Tue, Aug 4, 2020 at 10:28 AM James Smith <js5@sanger.ac.uk> wrote:
>
> >
> >
> >
> >
> > *From:* John Dunlap <John@lariat.co>
> > *Sent:* 04 August 2020 15:30
> > *To:* Wesley Peng <me@yonghua.org>
> > *Cc:* mod_perl list <modperl@perl.apache.org>
> > *Subject:* Re: suggestions for perl as web development language [EXT]
> >
> >
> >
> > The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
> >
> > > 1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork
> > because very few perl dependencies are thread safe.
> >
> >
> >
> > Concurrency in extreme conditions - is actually better when it comes to
> > mod_perl than a number of other solutions – e.g. nginx/starman.
> > Apache/mod_perl is much better at handling large numbers of simultaneous
> > requests than the systems which fork a number of small processes at start
> > up to handle requests. You either have to fork a large number of these or
> > pray you don’t get large numbers of simultaneous requests. Some of our
> > systems have long return times for queries due to the terra/petabyte scale
> > of some of our backend servers.
> >
> >
> >
> > > 2) mod_perl cannot provide web sockets.
> >
> >
> >
> > True – we haven’t really found an excuse for web-sockets although our
> > front end “Application Delivery Controller” (which sits in the DMZ) can
> > manage proxying requests that need sockets one way and others that don’t
> > another way.
> >
> > There are still a lot of issues with web-sockets – due to not all proxies
> > handling these requests and so have to limit their use in a lot our cases [.
> > a lot of our users are on networks that sit behind proxy/cache servers ]
> >
> >
> >
> > > Due to these reasons, my organization has started looking at ways to
> > move away from mod_perl.
> >
> >
> >
> > We are using more off the shelf packages for some of our applications –
> > e.g. Wordpress as a CMS/Object manager, and yes we are also moving to more
> > front-end centric applications. But many of our fundamental pieces of code
> > are still working in Apache/mod_perl as it is a better, more-reliable
> > language to work with.
> >
> >
> >
> >
> >
> > On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng <me@yonghua.org> wrote:
> >
> > greetings,
> >
> > My team use all of perl, ruby, python for scripting stuff.
> > perl is stronger for system admin tasks, and data analysis etc.
> > But for web development, it seems to be not as popular as others.
> > It has less selective frameworks, and even we can't get the right people
> > to do the webdev job with perl.
> > Do you think in today we will give up perl/modperl as web development
> > language, and choose the alternatives instead?
> >
> > Thanks & Regards
> >
> >
> >
> > --
> >
> > John Dunlap
> >
> > CTO | Lariat
> >
> >
> >
> > *Direct:*
> >
> > john@lariat.co
> >
> >
> > *Customer Service:*
> >
> > 877.268.6667
> >
> > support@lariat.co
> >
> > -- The Wellcome Sanger Institute is operated by Genome Research Limited, a
> > charity registered in England with number 1021457 and a company registered
> > in England with number 2742969, whose registered office is 215 Euston Road,
> > London, NW1 2BE.
> >



--
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

> On 4 Aug 2020, at 17:58, Mithun Bhattacharya <mithnb@gmail.com> wrote:
>
> mod_perl does have value because it does a more efficient utilization of resources - this is important when fast response time and scalability is important. The complexity is a known problem but it is not a mystery box either - there is enough documentation which explains what has to happen and what could have gone wrong.

mod_perl’s relative efficiency can be achieved by other well-known means.

I am genuinely curious what are these other "well known" means ?

On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman <mark@blackmans.org> wrote:

>
>
> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya <mithnb@gmail.com> wrote:
> >
> > mod_perl does have value because it does a more efficient utilization of
> resources - this is important when fast response time and scalability is
> important. The complexity is a known problem but it is not a mystery box
> either - there is enough documentation which explains what has to happen
> and what could have gone wrong.
>
> mod_perl’s relative efficiency can be achieved by other well-known means.

> On 4 Aug 2020, at 21:41, Mithun Bhattacharya <mithnb@gmail.com> wrote:
>
> I am genuinely curious what are these other "well known" means ?
>
> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman <mark@blackmans.org <mailto:mark@blackmans.org>> wrote:
>
>
> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya <mithnb@gmail.com <mailto:mithnb@gmail.com>> wrote:
> >
> > mod_perl does have value because it does a more efficient utilization of resources - this is important when fast response time and scalability is important. The complexity is a known problem but it is not a mystery box either - there is enough documentation which explains what has to happen and what could have gone wrong.
>
> mod_perl’s relative efficiency can be achieved by other well-known means.

That would depend on what you mean by "efficient utilisation of resources”. You can get the same general effect, more simply, by running a high-performing pre-forking Perl web application server and a web server with a simple configuration in front of it ,instead of a complicated Apache+mod_perl installation.

That also buys you a nice separation of concerns, the web server handles all the complicated host or path rewrites and access control and the Perl app focuses on responding to the, now-sanitised, fully normalized, HTTP requests.

- Mark

Ours is a REST based service so every request has business logic and an
apache+mod_perl instance actually has a better segregation of the
webserver and Perl code - we don't worry about handling the HTTP request
and managing children. We trust Apache will do the right thing and if
something breaks we have a large community of people who can help. All we
worry about is our business logic which well no one can help if we don't
know what we have coded :)

Would you like to share a Perl based webserver which can be guaranteed to
be comparable to apache in terms of reliability and stability ?

On Tue, Aug 4, 2020 at 3:48 PM Mark Blackman <mark@blackmans.org> wrote:

>
>
> On 4 Aug 2020, at 21:41, Mithun Bhattacharya <mithnb@gmail.com> wrote:
>
> I am genuinely curious what are these other "well known" means ?
>
> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman <mark@blackmans.org> wrote:
>
>>
>>
>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya <mithnb@gmail.com> wrote:
>> >
>> > mod_perl does have value because it does a more efficient utilization
>> of resources - this is important when fast response time and scalability is
>> important. The complexity is a known problem but it is not a mystery box
>> either - there is enough documentation which explains what has to happen
>> and what could have gone wrong.
>>
>> mod_perl’s relative efficiency can be achieved by other well-known means.
>
>
> That would depend on what you mean by "efficient utilisation of
> resources”. You can get the same general effect, more simply, by running a
> high-performing pre-forking Perl web application server and a web server
> with a simple configuration in front of it ,instead of a complicated
> Apache+mod_perl installation.
>
> That also buys you a nice separation of concerns, the web server handles
> all the complicated host or path rewrites and access control and the Perl
> app focuses on responding to the, now-sanitised, fully normalized, HTTP
> requests.
>
> - Mark
>
>
>
>

> On 4 Aug 2020, at 21:55, Mithun Bhattacharya <mithnb@gmail.com> wrote:
>
> Ours is a REST based service so every request has business logic and an apache+mod_perl instance actually has a better segregation of the webserver and Perl code - we don't worry about handling the HTTP request and managing children. We trust Apache will do the right thing and if something breaks we have a large community of people who can help. All we worry about is our business logic which well no one can help if we don't know what we have coded :)
>
> Would you like to share a Perl based webserver which can be guaranteed to be comparable to apache in terms of reliability and stability ?
>
> On Tue, Aug 4, 2020 at 3:48 PM Mark Blackman <mark@blackmans.org <mailto:mark@blackmans.org>> wrote:
>
>
>> On 4 Aug 2020, at 21:41, Mithun Bhattacharya <mithnb@gmail.com <mailto:mithnb@gmail.com>> wrote:
>>
>> I am genuinely curious what are these other "well known" means ?
>>
>> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman <mark@blackmans.org <mailto:mark@blackmans.org>> wrote:
>>
>>
>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya <mithnb@gmail.com <mailto:mithnb@gmail.com>> wrote:
>> >
>> > mod_perl does have value because it does a more efficient utilization of resources - this is important when fast response time and scalability is important. The complexity is a known problem but it is not a mystery box either - there is enough documentation which explains what has to happen and what could have gone wrong.
>>
>> mod_perl’s relative efficiency can be achieved by other well-known means.
>
> That would depend on what you mean by "efficient utilisation of resources”. You can get the same general effect, more simply, by running a high-performing pre-forking Perl web application server and a web server with a simple configuration in front of it ,instead of a complicated Apache+mod_perl installation.
>
> That also buys you a nice separation of concerns, the web server handles all the complicated host or path rewrites and access control and the Perl app focuses on responding to the, now-sanitised, fully normalized, HTTP requests.
>
> - Mark

You would still have something like Apache or Nginx handling the direct connection to the client and after all clean-up/rewrite/ACL logic is applied, then the HTTP request is passed onto something like https://metacpan.org/pod/Starman <https://metacpan.org/pod/Starman>

- Mark

I am not sure I understand - by the time we have decided we need perl why
not go for Apache and even consider an alternate ?

The mod_perl setup can't be the only criteria - we created a sample service
and demonstrated it to everyone in the team what needs to happen and now we
have services cropping up like mushrooms.

On Tue, Aug 4, 2020 at 4:05 PM Mark Blackman <mark@blackmans.org> wrote:

>
>
> On 4 Aug 2020, at 21:55, Mithun Bhattacharya <mithnb@gmail.com> wrote:
>
> Ours is a REST based service so every request has business logic and an
> apache+mod_perl instance actually has a better segregation of the
> webserver and Perl code - we don't worry about handling the HTTP request
> and managing children. We trust Apache will do the right thing and if
> something breaks we have a large community of people who can help. All we
> worry about is our business logic which well no one can help if we don't
> know what we have coded :)
>
> Would you like to share a Perl based webserver which can be guaranteed to
> be comparable to apache in terms of reliability and stability ?
>
> On Tue, Aug 4, 2020 at 3:48 PM Mark Blackman <mark@blackmans.org> wrote:
>
>>
>>
>> On 4 Aug 2020, at 21:41, Mithun Bhattacharya <mithnb@gmail.com> wrote:
>>
>> I am genuinely curious what are these other "well known" means ?
>>
>> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman <mark@blackmans.org> wrote:
>>
>>>
>>>
>>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya <mithnb@gmail.com> wrote:
>>> >
>>> > mod_perl does have value because it does a more efficient utilization
>>> of resources - this is important when fast response time and scalability is
>>> important. The complexity is a known problem but it is not a mystery box
>>> either - there is enough documentation which explains what has to happen
>>> and what could have gone wrong.
>>>
>>> mod_perl’s relative efficiency can be achieved by other well-known means.
>>
>>
>> That would depend on what you mean by "efficient utilisation of
>> resources”. You can get the same general effect, more simply, by running a
>> high-performing pre-forking Perl web application server and a web server
>> with a simple configuration in front of it ,instead of a complicated
>> Apache+mod_perl installation.
>>
>> That also buys you a nice separation of concerns, the web server handles
>> all the complicated host or path rewrites and access control and the Perl
>> app focuses on responding to the, now-sanitised, fully normalized, HTTP
>> requests.
>>
>> - Mark
>>
>
> You would still have something like Apache or Nginx handling the direct
> connection to the client and after all clean-up/rewrite/ACL logic is
> applied, then the HTTP request is passed onto something like
> https://metacpan.org/pod/Starman
>
> - Mark
>
>

Don’t talk to me about nginx/starman – it results in most of the errors with concurrency issues we see where I work – but doesn’t report the issues! We just see them when users can’t get responses.

The code written in mod_perl had no issues with about 25% of the resources. Starman fails under a large numbers of concurrent connections; admittedly some of requests can take seconds if not minutes to return (querying terra & peta byte scale databases) so it isn’t difficult to generate lots of concurrent queries.


From: Mark Blackman <mark@blackmans.org>
Sent: 04 August 2020 22:05
To: Mithun Bhattacharya <mithnb@gmail.com>
Cc: Joseph He <joseph.he.2008@gmail.com>; James Smith <js5@sanger.ac.uk>; John Dunlap <John@lariat.co>; Wesley Peng <me@yonghua.org>; mod_perl list <modperl@perl.apache.org>
Subject: Re: suggestions for perl as web development language [EXT]




On 4 Aug 2020, at 21:55, Mithun Bhattacharya <mithnb@gmail.com<mailto:mithnb@gmail.com>> wrote:

Ours is a REST based service so every request has business logic and an apache+mod_perl instance actually has a better segregation of the webserver and Perl code - we don't worry about handling the HTTP request and managing children. We trust Apache will do the right thing and if something breaks we have a large community of people who can help. All we worry about is our business logic which well no one can help if we don't know what we have coded :)

Would you like to share a Perl based webserver which can be guaranteed to be comparable to apache in terms of reliability and stability ?

On Tue, Aug 4, 2020 at 3:48 PM Mark Blackman <mark@blackmans.org<mailto:mark@blackmans.org>> wrote:



On 4 Aug 2020, at 21:41, Mithun Bhattacharya <mithnb@gmail.com<mailto:mithnb@gmail.com>> wrote:

I am genuinely curious what are these other "well known" means ?

On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman <mark@blackmans.org<mailto:mark@blackmans.org>> wrote:


> On 4 Aug 2020, at 17:58, Mithun Bhattacharya <mithnb@gmail.com<mailto:mithnb@gmail.com>> wrote:
>
> mod_perl does have value because it does a more efficient utilization of resources - this is important when fast response time and scalability is important. The complexity is a known problem but it is not a mystery box either - there is enough documentation which explains what has to happen and what could have gone wrong.

mod_perl’s relative efficiency can be achieved by other well-known means.

That would depend on what you mean by "efficient utilisation of resources”. You can get the same general effect, more simply, by running a high-performing pre-forking Perl web application server and a web server with a simple configuration in front of it ,instead of a complicated Apache+mod_perl installation.

That also buys you a nice separation of concerns, the web server handles all the complicated host or path rewrites and access control and the Perl app focuses on responding to the, now-sanitised, fully normalized, HTTP requests.

- Mark

You would still have something like Apache or Nginx handling the direct connection to the client and after all clean-up/rewrite/ACL logic is applied, then the HTTP request is passed onto something like https://metacpan.org/pod/Starman [metacpan.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__metacpan.org_pod_Starman&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=9Iq3_XmWnDBY_X_sLWU5TBxlUOACnWsTzq5FSwl4lps&s=-fjwi06iac3C4zq2yJFdm8lAb8927XTfCwOHbFBwvzk&e=>

- Mark




--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

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 <ruben@mrbrklyn.com>
Sent: Wednesday, 5 August 2020 5:14 AM
To: Andr? Warnier (tomcat/perl) <aw@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