subject:"suggestions for perl as web development language \[EXT\]"

Running individual functions in independent threads can't be a solution for
performance optimization - at least I have never heard such a thing, maybe
others can pitch in.

On Sun, Dec 20, 2020 at 4:15 PM John Dunlap  wrote:

> I have no doubt that our application can be optimized. We do so whenever
> we encounter poor performance and we will continue to do so. The point is
> that Perl didn't do a lot to help us in this regard. Languages like elixir
> use immutable data structures and will automatically run individual
> function calls in separate threads. Perl, by contrast, will only have a
> single thread per request.
>
> On Sun, Dec 20, 2020, 3:33 PM Mithun Bhattacharya 
> wrote:
>
>> You would have to define poor system performance - are you doing anything
>> cpu intensive at all ? Maybe your RAM is being the bottleneck ?
>>
>> On Sun, Dec 20, 2020 at 2:28 PM John Dunlap  wrote:
>>
>>> It's extremely inefficient by comparison. We host our application on
>>> beefy servers with 32 cores and 64G of ram and I commonly see poor system
>>> performance with less than 25% cpu utilization.
>>>
>>> On Sun, Dec 20, 2020, 2:22 PM Mithun Bhattacharya 
>>> wrote:
>>>
>>>> Agreed prefork is recommended but what is the problem with that ?
>>>>
>>>> On Sun, Dec 20, 2020 at 12:47 PM John Dunlap  wrote:
>>>>
>>>>> Our app segfaults at random of we use anything other than prefork.
>>>>>
>>>>> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya 
>>>>> wrote:
>>>>>
>>>>>> I am confused - you like threads so Perl is bad ? I am very happy
>>>>>> forking away and yes I work a lot with non thread safe DBI connections
>>>>>> without any issues.
>>>>>>
>>>>>> On Sun, Dec 20, 2020 at 11:53 AM John Dunlap  wrote:
>>>>>>
>>>>>>> In my opinion, no one should build new projects in Perl. The world
>>>>>>> is increasingly trending towards parallelism and higher numbers of cpu
>>>>>>> cores and Perl is poorly positioned to leverage these advancements. 
>>>>>>> Many of
>>>>>>> Perl's dependencies are not thread safe and mod_perl forces you to use
>>>>>>> mpm_prefork. My organization has started moving away from Perl to Elixir
>>>>>>> for these reasons.
>>>>>>>
>>>>>>> On Tue, Aug 4, 2020, 3:37 AM 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.
>>>>>>>>
>>>>>>>> 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 mojoli

Re: suggestions for perl as web development language [EXT]

You would have to define poor system performance - are you doing anything
cpu intensive at all ? Maybe your RAM is being the bottleneck ?

On Sun, Dec 20, 2020 at 2:28 PM John Dunlap  wrote:

> It's extremely inefficient by comparison. We host our application on beefy
> servers with 32 cores and 64G of ram and I commonly see poor system
> performance with less than 25% cpu utilization.
>
> On Sun, Dec 20, 2020, 2:22 PM Mithun Bhattacharya 
> wrote:
>
>> Agreed prefork is recommended but what is the problem with that ?
>>
>> On Sun, Dec 20, 2020 at 12:47 PM John Dunlap  wrote:
>>
>>> Our app segfaults at random of we use anything other than prefork.
>>>
>>> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya 
>>> wrote:
>>>
>>>> I am confused - you like threads so Perl is bad ? I am very happy
>>>> forking away and yes I work a lot with non thread safe DBI connections
>>>> without any issues.
>>>>
>>>> On Sun, Dec 20, 2020 at 11:53 AM John Dunlap  wrote:
>>>>
>>>>> In my opinion, no one should build new projects in Perl. The world is
>>>>> increasingly trending towards parallelism and higher numbers of cpu cores
>>>>> and Perl is poorly positioned to leverage these advancements. Many of
>>>>> Perl's dependencies are not thread safe and mod_perl forces you to use
>>>>> mpm_prefork. My organization has started moving away from Perl to Elixir
>>>>> for these reasons.
>>>>>
>>>>> On Tue, Aug 4, 2020, 3:37 AM 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.
>>>>>>
>>>>>> 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 
>>>>>> 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.
>>>>>
>>>>>

Re: suggestions for perl as web development language [EXT]

Your external facing apache instance would do the SSL part and use
mod_proxy to redirect the request to another instance of apache which
implements the actual functionality. Just remember the second instance
needs to run on a different port and that it doesnt have to talk to the
outside world.

Did you check out the practical mod_perl article ?
https://docstore.mik.ua/orelly/weblinux2/modperl/ch12_07.htm

As for your Lets Encrypt certificate - autorenewal isnt a mod_perl thing
rather you do have to place a script in some sort of scheduler.
https://onepagezen.com/letsencrypt-auto-renew-certbot-apache

On Sun, Dec 20, 2020 at 1:45 PM Tom Browder  wrote:

> On Sun, Dec 20, 2020 at 11:29 Mithun Bhattacharya 
> wrote:
>
>> Just curious where exactly is the challenge in this setup ? It can't be
>> in apache supporting real certificates - neither can it be in setting up
>> reverse proxy internally...
>>
>
> The challenge to me is how exactly to code the reverse proxy on a single
> instance of Apache. I have found no one who can tell me exactly how to
> manage https in the http conf file between the outward facing side and
> inside the reverse proxy so that the auto-tls renewal works with Let's
> Encrypt, all on a single server.
>
> I think I could cobble together a cron job to do it, but not without a lot
> of trial and error, especially when I'm not sure how the proxy and proxy
> pass are supposed to look.
>
> I sure wish someone would update the old Apache Cookbook.
>
> -Tom
>
>

Re: suggestions for perl as web development language [EXT]

2020-12-20 Thread Tom Browder

On Sun, Dec 20, 2020 at 11:29 Mithun Bhattacharya  wrote:

> Just curious where exactly is the challenge in this setup ? It can't be in
> apache supporting real certificates - neither can it be in setting up
> reverse proxy internally...
>

The challenge to me is how exactly to code the reverse proxy on a single
instance of Apache. I have found no one who can tell me exactly how to
manage https in the http conf file between the outward facing side and
inside the reverse proxy so that the auto-tls renewal works with Let's
Encrypt, all on a single server.

I think I could cobble together a cron job to do it, but not without a lot
of trial and error, especially when I'm not sure how the proxy and proxy
pass are supposed to look.

I sure wish someone would update the old Apache Cookbook.

-Tom

Re: suggestions for perl as web development language [EXT]

Agreed prefork is recommended but what is the problem with that ?

On Sun, Dec 20, 2020 at 12:47 PM John Dunlap  wrote:

> Our app segfaults at random of we use anything other than prefork.
>
> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya 
> wrote:
>
>> I am confused - you like threads so Perl is bad ? I am very happy forking
>> away and yes I work a lot with non thread safe DBI connections without any
>> issues.
>>
>> On Sun, Dec 20, 2020 at 11:53 AM John Dunlap  wrote:
>>
>>> In my opinion, no one should build new projects in Perl. The world is
>>> increasingly trending towards parallelism and higher numbers of cpu cores
>>> and Perl is poorly positioned to leverage these advancements. Many of
>>> Perl's dependencies are not thread safe and mod_perl forces you to use
>>> mpm_prefork. My organization has started moving away from Perl to Elixir
>>> for these reasons.
>>>
>>> On Tue, Aug 4, 2020, 3:37 AM 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.
>>>>
>>>> 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 
>>>> 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.
>>>
>>>

Re: suggestions for perl as web development language [EXT]

I am confused - you like threads so Perl is bad ? I am very happy forking
away and yes I work a lot with non thread safe DBI connections without any
issues.

On Sun, Dec 20, 2020 at 11:53 AM John Dunlap  wrote:

> In my opinion, no one should build new projects in Perl. The world is
> increasingly trending towards parallelism and higher numbers of cpu cores
> and Perl is poorly positioned to leverage these advancements. Many of
> Perl's dependencies are not thread safe and mod_perl forces you to use
> mpm_prefork. My organization has started moving away from Perl to Elixir
> for these reasons.
>
> On Tue, Aug 4, 2020, 3:37 AM 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.
>>
>> 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 
>> 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.
>
>

Re: suggestions for perl as web development language [EXT]

2020-12-20 Thread John Dunlap

In my opinion, no one should build new projects in Perl. The world is
increasingly trending towards parallelism and higher numbers of cpu cores
and Perl is poorly positioned to leverage these advancements. Many of
Perl's dependencies are not thread safe and mod_perl forces you to use
mpm_prefork. My organization has started moving away from Perl to Elixir
for these reasons.

On Tue, Aug 4, 2020, 3:37 AM 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.
>
> 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 
> 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.

Re: suggestions for perl as web development language [EXT]

Just curious where exactly is the challenge in this setup ? It can't be in
apache supporting real certificates - neither can it be in setting up
reverse proxy internally...

On Sun, Dec 20, 2020 at 11:19 AM Tom Browder  wrote:

>
>
> On Sun, Dec 20, 2020 at 09:33 Steven Lembark  wrote:
>
>> On Tue, 4 Aug 2020 18:05:28 -0700
>> jbiskofski  wrote:
>>
>> > I had a hard time accepting this was a good configuration because for
>> > 20 years I had thought of webservers as big giant compiled systems
>> > (apache), but apparently you can now create something just as fast in
>> > Perl.
>>
>> And a helluva lot easier to install, manage, develop on, and maintain.
>
>
> Steven,  I have met you at a couple of Perl conferences and know you know
> Raku as well. One thing that has always bothered me about PSGI, Catalyst,
> mod_fcgi, etc., is that I could never find a practical cookbook solution
> for a simple but working dynamic and publicly available https website on a
> real, modern Apache 2.4 server on a Linux bare-metal, sole user remote
> server.
>
> I would love to be able to have something similar for Raku, and there is
> Cro, but it so far cannot handle auto-generation of Let's Encrypt TLS
> certificates with a reverse proxy on Apache.
>
> As an alternative, I would be happy to run with a Perl solution iif it
> could handle my TLS requirement. Any suggestions will be greatly
> appreciated.
>
> BTW, I have publicly documented my current Apache setup (non-dynamic
> except for limited CGI use on a couple of sites). The Apache uses nearly
> the latest Apache and OpenSSL compiled from source. It includes multiple
> (15 or so at last count) virtual hosts (using macros for extremely easy
> deployment). It was last updated mid-2020 and I'll be looking to update it
> next year. It's on Github and I'll send the reference if anyone wants it.
>
> Blessings,
>
> -Tom
>

Re: suggestions for perl as web development language [EXT]

2020-12-20 Thread Tom Browder

On Sun, Dec 20, 2020 at 09:33 Steven Lembark  wrote:

> On Tue, 4 Aug 2020 18:05:28 -0700
> jbiskofski  wrote:
>
> > I had a hard time accepting this was a good configuration because for
> > 20 years I had thought of webservers as big giant compiled systems
> > (apache), but apparently you can now create something just as fast in
> > Perl.
>
> And a helluva lot easier to install, manage, develop on, and maintain.

Steven,  I have met you at a couple of Perl conferences and know you know
Raku as well. One thing that has always bothered me about PSGI, Catalyst,
mod_fcgi, etc., is that I could never find a practical cookbook solution
for a simple but working dynamic and publicly available https website on a
real, modern Apache 2.4 server on a Linux bare-metal, sole user remote
server.

I would love to be able to have something similar for Raku, and there is
Cro, but it so far cannot handle auto-generation of Let's Encrypt TLS
certificates with a reverse proxy on Apache.

As an alternative, I would be happy to run with a Perl solution iif it
could handle my TLS requirement. Any suggestions will be greatly
appreciated.

BTW, I have publicly documented my current Apache setup (non-dynamic except
for limited CGI use on a couple of sites). The Apache uses nearly the
latest Apache and OpenSSL compiled from source. It includes multiple (15 or
so at last count) virtual hosts (using macros for extremely easy
deployment). It was last updated mid-2020 and I'll be looking to update it
next year. It's on Github and I'll send the reference if anyone wants it.

Blessings,

-Tom

RE: suggestions for perl as web development language [EXT]

2020-12-20 Thread James Smith

There are cases where Plack though isn't the solution and where mod_perl 
written well is a far better (more stable) solution.

It is good when the backend servers are slow (simple not complex app); backend 
requests are relatively fast, and don't use much memory.

But the warning

(1) If you have large numbers of small apps on a domain (a couple we have have 
over 60 admin apps under a single domain) or a large single app code base - but 
where many of the larger requests are hardly used; the ability to choose which 
perl is cached in shared memory and which is loaded when required is much 
simpler;
(2) Large code bases can also lead to very slow start-up times;
(3) If there are possibilities of large/slow requests - apache's dynamic nature 
is better and handling these and then clearing memory - issues with each Plack 
process keeping large amounts of memory and difficulty in culling/restarting 
individual Plack children; then handling load efficiently across multiple 
machines as the front end proxies - have difficulty handling load balancing in 
this case;

Note I work on a number of projects where the data is relatively large (some 
including many billions of rows of (closely related) entries)

-Original Message-
From: Steven Lembark  
Sent: 20 December 2020 15:31
To: modperl@perl.apache.org
Cc: lemb...@wrkhors.com
Subject: Re: suggestions for perl as web development language [EXT]

On Tue, 4 Aug 2020 19:59:01 -0500
Mithun Bhattacharya  wrote:

> The question is move off to what ? I don't see alternatives being 
> shared which blows an apache+mod_perl setup out of the water.

(Sorry for being late on this...)

There are a variety of servers using Plack which can handle heavy loads and are 
both better documented and easier to manage than Apache. You can see a list at:

<https://urldefense.proofpoint.com/v2/url?u=https-3A__plackperl.org_=DwICAg=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=oH2yp0ge1ecj4oDX0XM7vQ=0pvlZHIoJPSsNhAVAVBL0NMNcYWvoQoOAVEPR_qHMJo=O1eJE9v7RhxcM7aaINIPmQv8R8CZSbIRwuxV2rLqHXA=
 >

One big advantage to Plack is *not* having to become a walking encyclopedia of 
Apache2 internals. Shoving structs around was the only way we knew in the 80's, 
mod_perl was just an extension of "pass a struct" and keep going. Plack 
provides an abstraction that at least I find simpler to program with and things 
like Dancer2 give you the opportunity to munge the incoming request in all 
sorts of ways to handle messy situations. Beyond that take a look at the 
servers listed on Plack's website.

--
Steven Lembark
Workhorse Computing
lemb...@wrkhors.com
+1 888 359 3508

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

Re: suggestions for perl as web development language [EXT]

2020-12-20 Thread Steven Lembark

On Tue, 4 Aug 2020 18:05:28 -0700
jbiskofski  wrote:

> I had a hard time accepting this was a good configuration because for
> 20 years I had thought of webservers as big giant compiled systems
> (apache), but apparently you can now create something just as fast in
> Perl.

And a helluva lot easier to install, manage, develop on, and maintain.


-- 
Steven Lembark
Workhorse Computing
lemb...@wrkhors.com
+1 888 359 3508

Re: suggestions for perl as web development language [EXT]

2020-12-20 Thread Steven Lembark

On Tue, 4 Aug 2020 19:59:01 -0500
Mithun Bhattacharya  wrote:

> The question is move off to what ? I don't see alternatives being
> shared which blows an apache+mod_perl setup out of the water.

(Sorry for being late on this...)

There are a variety of servers using Plack which can handle heavy 
loads and are both better documented and easier to manage than
Apache. You can see a list at:

One big advantage to Plack is *not* having to become a walking 
encyclopedia of Apache2 internals. Shoving structs around was the
only way we knew in the 80's, mod_perl was just an extension of
"pass a struct" and keep going. Plack provides an abstraction that
at least I find simpler to program with and things like Dancer2 
give you the opportunity to munge the incoming request in all sorts
of ways to handle messy situations. Beyond that take a look at the
servers listed on Plack's website.

-- 
Steven Lembark
Workhorse Computing
lemb...@wrkhors.com
+1 888 359 3508

Re: suggestions for perl as web development language [EXT]

2020-08-05 Thread tomcat/perl

On 04.08.2020 22:48, Mark Blackman wrote:
[...]
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.

I'll agree to that, up to a point.

If you just want to write web applications which run in a sanitized, normalised HTTP
environment, then there are plenty of tools available, and your best choice nowadays may
not be perl as a development language.

(*)

Now in the real world, you may often have to do things which do NOT fit in such a
sanitized and normalized environment, and the simplest and most efficient way to do them
may be at the level of the HTTP server itself. And if you are in such a case, and if your
webserver is Apache httpd, then for such things mod_perl has no equivalent (except if you
are very good at writing Apache httpd extensions in C).

And in my experience - although I don't know if this is an advantage or an inconvenient in
a general sense - once you start using mod_perl to resolve such issues, you will be
learning a lot about how Apache httpd works, and how mod_perl fits in it, and you will
start finding out how many of these apparently thorny issues /can/ be handled at the
Apache httpd and mod_perl level, and you will probably never want to go back to work with
another webserver and another scripting language for it.

So be careful : Apache httpd + mod_perl are addictive.

(*) Although if you pick another language, then you would also lose the advantage of the
perl CPAN library which has, *in one place*, something for just about everything you may
ever want to do - including very good documentation on just about everything you may ever
want to do).
If you don't know CPAN, and you do not understand why I'm insisting on it, do the
following experience :

- go to https://metacpan.org/
- in the search box, type a word related to some programming issue which you are currently
having (**)

- then read the descriptions and click on some module which looks interesting
for you

In terms of programming, this is as close to Wikipedia as one can get.
Thanks to the hundreds of authors who contributed there over the year, and to their
general care about good documentation.

For me, that alone is already enough justification for using perl.

(**) suggestions, of the top of my head : "covid", "usa", "png", "soap", "ldap",
"calculus", "spanish", "mail", "smtp", "ebay", "dictionary", .. have fun.

Re: suggestions for perl as web development language [EXT]

Mojo is good but it is specifically for fast non blocking services. If you
are trying to pull up old monolithic applications into the service based
world it might take significant rewrite or you use apache/mod_perl :)

On Tue, Aug 4, 2020 at 8:05 PM jbiskofski  wrote:

> Mod Perl is awesome. That said, the cool kids today are all about Plack.
>
> Google: Dancer, Mojolicious, Catalyst. These allow you to plugin to all
> parts of the HTTP protocol, but obviously not to modify apache
> configuration.
> Excelent, stable, FAST, production ready HTTP server: Starman
> Even faster, but not as proven: Twiggy.
>
> The most common setup would be with an Nginx process in front.
>
> I had a hard time accepting this was a good configuration because for 20
> years I had thought of webservers as big giant compiled systems (apache),
> but apparently you can now create something just as fast in Perl.
>
>
>
> On Tue, Aug 4, 2020 at 5:59 PM Mithun Bhattacharya 
> wrote:
>
>> The question is move off to what ? I don't see alternatives being shared
>> which blows an apache+mod_perl setup out of the water.
>>
>> On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:
>>
>>> On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
>>> >
>>> >
>>> > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya 
>>> wrote:
>>> > >
>>> > > I am genuinely curious what are these other "well known" means ?
>>> > >
>>> > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman >> > wrote:
>>> > >
>>> > >
>>> > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya >> > 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.
>>> >
>>>
>>> Not really and the separtion is not a concern, it is an asset, the most
>>> important one.
>>>
>>> To get faster, you would need to move off apache.
>>>
>>>
>>> > - Mark
>>> >
>>> >
>>> >
>>>
>>> --
>>> 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
>>>
>>>

Re: suggestions for perl as web development language [EXT]

2020-08-04 Thread Wesley Peng





jbiskofski wrote:

Excelent, stable, FAST, production ready HTTP server: Starman


yes starman is good. we use it for rest-api service, the app code is 
dancer, whose backend server is starman.


if we need more concurrent handlers, a simple front-proxy like nginx 
would be deployed.


regards.

Re: suggestions for perl as web development language [EXT]

Haha my service is meant to be a blackbox - of course it talks to three
different REST services :)

On Tue, Aug 4, 2020 at 8:05 PM Ruben Safir  wrote:

> On Tue, Aug 04, 2020 at 07:59:01PM -0500, Mithun Bhattacharya wrote:
> > The question is move off to what ? I don't see alternatives being shared
> > which blows an apache+mod_perl setup out of the water.
> >
>
>
> Maybe JBoss
>
> really there is none.  mod_perl turns apache into an application server,
> and there is not much like it, where it can get you right into the heart
> of the Apache response cycle.
>
> If you want something that talks to 3 jsom servers and exposes your data
> all over the net, you can do this with mod_perl, but it is not something
> that would interest most mod_perl coders.
>
>
> > On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:
> >
> > > On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
> > > >
> > > >
> > > > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya 
> wrote:
> > > > >
> > > > > I am genuinely curious what are these other "well known" means ?
> > > > >
> > > > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > > > wrote:
> > > > >
> > > > >
> > > > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > > > 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.
> > > >
> > >
> > > Not really and the separtion is not a concern, it is an asset, the most
> > > important one.
> > >
> > > To get faster, you would need to move off apache.
> > >
> > >
> > > > - Mark
> > > >
> > > >
> > > >
> > >
> > > --
> > > 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
> > >
> > >
>
> --
> 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
>
>

Re: suggestions for perl as web development language [EXT]

On Tue, Aug 04, 2020 at 07:59:01PM -0500, Mithun Bhattacharya wrote:
> The question is move off to what ? I don't see alternatives being shared
> which blows an apache+mod_perl setup out of the water.
> 


Maybe JBoss

really there is none.  mod_perl turns apache into an application server,
and there is not much like it, where it can get you right into the heart
of the Apache response cycle.

If you want something that talks to 3 jsom servers and exposes your data
all over the net, you can do this with mod_perl, but it is not something
that would interest most mod_perl coders.


> On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:
> 
> > On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
> > >
> > >
> > > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
> > > >
> > > > I am genuinely curious what are these other "well known" means ?
> > > >
> > > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > > wrote:
> > > >
> > > >
> > > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > > 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.
> > >
> >
> > Not really and the separtion is not a concern, it is an asset, the most
> > important one.
> >
> > To get faster, you would need to move off apache.
> >
> >
> > > - Mark
> > >
> > >
> > >
> >
> > --
> > 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
> >
> >

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

Re: suggestions for perl as web development language [EXT]

2020-08-04 Thread jbiskofski

Mod Perl is awesome. That said, the cool kids today are all about Plack.

Google: Dancer, Mojolicious, Catalyst. These allow you to plugin to all
parts of the HTTP protocol, but obviously not to modify apache
configuration.
Excelent, stable, FAST, production ready HTTP server: Starman
Even faster, but not as proven: Twiggy.

The most common setup would be with an Nginx process in front.

I had a hard time accepting this was a good configuration because for 20
years I had thought of webservers as big giant compiled systems (apache),
but apparently you can now create something just as fast in Perl.



On Tue, Aug 4, 2020 at 5:59 PM Mithun Bhattacharya  wrote:

> The question is move off to what ? I don't see alternatives being shared
> which blows an apache+mod_perl setup out of the water.
>
> On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:
>
>> On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
>> >
>> >
>> > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya 
>> wrote:
>> > >
>> > > I am genuinely curious what are these other "well known" means ?
>> > >
>> > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman > > wrote:
>> > >
>> > >
>> > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya > > 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.
>> >
>>
>> Not really and the separtion is not a concern, it is an asset, the most
>> important one.
>>
>> To get faster, you would need to move off apache.
>>
>>
>> > - Mark
>> >
>> >
>> >
>>
>> --
>> 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
>>
>>

Re: suggestions for perl as web development language [EXT]

On Wed, Aug 05, 2020 at 10:32:39AM +1000, dc...@prosentient.com.au wrote:
> 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. 

When one reads replies like this you tend to just /dev/null to sender
and shrug your shoulders.

Thanks for working out the exact math for us.  Your points are
excellent.

Re: suggestions for perl as web development language [EXT]

The question is move off to what ? I don't see alternatives being shared
which blows an apache+mod_perl setup out of the water.

On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:

> On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
> >
> >
> > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
> > >
> > > I am genuinely curious what are these other "well known" means ?
> > >
> > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > wrote:
> > >
> > >
> > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > 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.
> >
>
> Not really and the separtion is not a concern, it is an asset, the most
> important one.
>
> To get faster, you would need to move off apache.
>
>
> > - Mark
> >
> >
> >
>
> --
> 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
>
>

Re: suggestions for perl as web development language [EXT]

Just because the language lets you to relax doesn't mean you
shouldn't apply strict validation of all data being worked on :) I don't
care about it in a two line cron job but more critical components spend a
lot of time on data validation - I am pretty much working in paranoid mode.

If you use Moose you can automatically apply data type checking.

On Tue, Aug 4, 2020 at 7:47 PM Wesley Peng  wrote:

>
>
> 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.
>
> Maybe I am weak on this point, but how perl handle types more strictly?
> for example,
>
> 123 + '456'
>
> this is permitted in perl, and this is dangerous. It is not possible in
> other strong types language.
>
> Thanks.
>

Re: suggestions for perl as web development language [EXT]

On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
> 
> 
> > On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
> > 
> > I am genuinely curious what are these other "well known" means ?
> > 
> > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > > wrote:
> > 
> > 
> > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > > > 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.
> 

Not really and the separtion is not a concern, it is an asset, the most
important one.

To get faster, you would need to move off apache.


> - Mark
> 
> 
> 

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

Re: suggestions for perl as web development language [EXT]

2020-08-04 Thread Wesley Peng


Hi

Mark Blackman wrote:

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


for example?

thank you.

Re: suggestions for perl as web development language [EXT]

2020-08-04 Thread Wesley Peng





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.


Maybe I am weak on this point, but how perl handle types more strictly?
for example,

123 + '456'

this is permitted in perl, and this is dangerous. It is not possible in 
other strong types language.


Thanks.

RE: suggestions for perl as web development language [EXT]

2020-08-04 Thread dcook

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  
Sent: Wednesday, 5 August 2020 5:14 AM
To: André Warnier (tomcat/perl) 
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 
> applicatio

RE: suggestions for perl as web development language [EXT]

2020-08-04 Thread James Smith

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 
Sent: 04 August 2020 22:05
To: Mithun Bhattacharya 
Cc: Joseph He ; James Smith ; John 
Dunlap ; Wesley Peng ; mod_perl list 

Subject: Re: suggestions for perl as web development language [EXT]

On 4 Aug 2020, at 21:55, Mithun Bhattacharya 
mailto:mit...@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 
mailto:m...@blackmans.org>> wrote:

On 4 Aug 2020, at 21:41, Mithun Bhattacharya 
mailto:mit...@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 
mailto:m...@blackmans.org>> wrote:

> On 4 Aug 2020, at 17:58, Mithun Bhattacharya 
> mailto:mit...@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=DwMFaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=oH2yp0ge1ecj4oDX0XM7vQ=9Iq3_XmWnDBY_X_sLWU5TBxlUOACnWsTzq5FSwl4lps=-fjwi06iac3C4zq2yJFdm8lAb8927XTfCwOHbFBwvzk=>

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

Re: suggestions for perl as web development language [EXT]

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

>
>
> On 4 Aug 2020, at 21:55, Mithun Bhattacharya  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  wrote:
>
>>
>>
>> On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
>>
>> I am genuinely curious what are these other "well known" means ?
>>
>> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  wrote:
>>
>>>
>>>
>>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  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
>
>

Re: suggestions for perl as web development language [EXT]



> On 4 Aug 2020, at 21:55, Mithun Bhattacharya  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  > wrote:
> 
> 
>> On 4 Aug 2020, at 21:41, Mithun Bhattacharya > > wrote:
>> 
>> I am genuinely curious what are these other "well known" means ?
>> 
>> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman > > wrote:
>> 
>> 
>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya > > > 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

Re: suggestions for perl as web development language [EXT]

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

>
>
> On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
>
> I am genuinely curious what are these other "well known" means ?
>
> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  wrote:
>
>>
>>
>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  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
>
>
>
>

Re: suggestions for perl as web development language [EXT]

> On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
> 
> I am genuinely curious what are these other "well known" means ?
> 
> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > wrote:
> 
> 
> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > > 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

Re: suggestions for perl as web development language [EXT]

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

On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  wrote:

>
>
> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  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.

Re: suggestions for perl as web development language [EXT]




> On 4 Aug 2020, at 17:58, Mithun Bhattacharya  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.

Re: suggestions for perl as web development language [EXT]

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  wrote:
> 
> >
> >
> >
> >
> > *From:* John Dunlap 
> > *Sent:* 04 August 2020 15:30
> > *To:* Wesley Peng 
> > *Cc:* mod_perl list 
> > *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  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:*
> >
> > j...@lariat.co
> >
> >
> > *Customer Service:*
> >
> > 877.268.6667
> >
> > supp...@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

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

Re: suggestions for perl as web development language [EXT]

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

>
>
> > On 4 Aug 2020, at 17:42, 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.
> >
>
> 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

Re: suggestions for perl as web development language [EXT]

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  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  wrote:
>
>>
>>
>>
>>
>> *From:* John Dunlap 
>> *Sent:* 04 August 2020 15:30
>> *To:* Wesley Peng 
>> *Cc:* mod_perl list 
>> *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  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:*
>>
>> j...@lariat.co
>>
>>
>> *Customer Service:*
>>
>> 877.268.6667
>>
>> supp...@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.
>>
>

Re: suggestions for perl as web development language [EXT]