You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Paul Silevitch <pa...@silevitch.com> on 2018/07/29 20:18:54 UTC
Re: Future MPM Support?
Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
I'm currently using prefork but thought people were using worker in
production (assuming the application is thread safe). Is that not the case?
Paul
On Sat, Jun 9, 2018 at 7:03 AM, Dr James Smith <js...@sanger.ac.uk> wrote:
> No - because of the way it works it handles the request inside apache -
> the worker/event systems work by handing the request back to another
> process or processes in the background which handles the request and then
> returns - which is where the problem lies in the fact that you are
> effectively adding a proxy layer between the web-request and the actual
> perl process...
>
> It limits what you can do with Plack when it comes to handling aspects of
> the request which are better handled outside the main response phase {e.g.
> re-write, logging, cleanup etc} which limits functionality - most people
> who just use response handlers do not see this issue. But we hook into
> about 10 phases of the apache process ...
>
> On 08/06/2018 02:08, John Dunlap wrote:
>
> Does using mod_perl properly allow you to use mpm_event or mpm_worker?
>
> On Thu, Jun 7, 2018 at 9:19 PM, Dr James Smith <js...@sanger.ac.uk> wrote:
>
>> Unfortunately Plack (and Catalyst especially) are a fairly poor
>> comparison to using mod_perl properly {unfortunately very few people do so}
>> I've looked at Dancer and Catalyst - both are OK at what they do - but they
>> don't really handle things in the really clean easy way that mod_perl does
>> {if you attach code to the right handlers/filters} meaning chopping in and
>> changing code can be quite difficult in them.
>>
>> Both are good for simplish applications {yes and I've seen complex apps
>> written in them as well - but they usually need a lot more hardware support
>> than the equivalent mod_perl app to cope with demand}
>>
>> Unfortunately writing good mod_perl apps is hard - and so few mod_perl
>> apps really make use of the underlying framework properly - effectively
>> using it for code caching and not much else
>>
>>
>>
>> On 07/06/2018 19:24, David Hodgkinson wrote:
>>
>> Moving your method handlers to the framework.
>>
>> I like catalyst. Stand on the shoulders of giants. Mojolicious makes me
>> itch.
>>
>> On 7 Jun 2018, at 19:21, John Dunlap <jo...@lariat.co> wrote:
>>
>> What is involved in porting an application from mod_perl to starman?
>>
>> Throwing away logic and logical structure and replacing it with a much
>> less flexible approach...
>>
>> On Thu, Jun 7, 2018 at 6:18 PM, Clive Eisen <cl...@hildebrand.co.uk>
>> wrote:
>>
>>> On 7 Jun 2018, at 19:13, David Hodgkinson <da...@gmail.com> wrote:
>>>
>>> No. Different concept.
>>>
>>> On 7 Jun 2018, at 18:52, John Dunlap <jo...@lariat.co> wrote:
>>>
>>> Is Plack backwards compatible with mod_perl?
>>>
>>> On Thu, Jun 7, 2018 at 5:44 PM, David Hodgkinson <da...@gmail.com>
>>> wrote:
>>>
>>>> We’re all about the Plack these days.
>>>>
>>>>
>>> This.
>>>
>>> We have moved entirely to
>>>
>>> nginx (doing the ssl where appropriate) -> starman (which uses plack)
>>> and Dancer2
>>>
>>> Life is a LOT better
>>>
>>> —
>>> Clive
>>>
>>>
>>
>>
>> --
>> John Dunlap
>> *CTO | Lariat *
>>
>> *Direct:*
>> *john@lariat.co <jo...@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
>> <https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
>>
>>
>
>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *john@lariat.co <jo...@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
> <https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
>
>
Re: Future MPM Support?
Posted by John Dunlap <jo...@lariat.co>.
prefork is, currently, is still the only MPM which works reliably for us.
The others segfault at seemingly random intervals.
On Sun, Jul 29, 2018 at 8:18 PM, Paul Silevitch <pa...@silevitch.com> wrote:
> Like Dr. James Smith, I'm hooking into multiple handlers and using
> filters. I'm currently using prefork but thought people were using worker
> in production (assuming the application is thread safe). Is that not the
> case?
>
> Paul
>
> On Sat, Jun 9, 2018 at 7:03 AM, Dr James Smith <js...@sanger.ac.uk> wrote:
>
>> No - because of the way it works it handles the request inside apache -
>> the worker/event systems work by handing the request back to another
>> process or processes in the background which handles the request and then
>> returns - which is where the problem lies in the fact that you are
>> effectively adding a proxy layer between the web-request and the actual
>> perl process...
>>
>> It limits what you can do with Plack when it comes to handling aspects of
>> the request which are better handled outside the main response phase {e.g.
>> re-write, logging, cleanup etc} which limits functionality - most people
>> who just use response handlers do not see this issue. But we hook into
>> about 10 phases of the apache process ...
>>
>> On 08/06/2018 02:08, John Dunlap wrote:
>>
>> Does using mod_perl properly allow you to use mpm_event or mpm_worker?
>>
>> On Thu, Jun 7, 2018 at 9:19 PM, Dr James Smith <js...@sanger.ac.uk> wrote:
>>
>>> Unfortunately Plack (and Catalyst especially) are a fairly poor
>>> comparison to using mod_perl properly {unfortunately very few people do so}
>>> I've looked at Dancer and Catalyst - both are OK at what they do - but they
>>> don't really handle things in the really clean easy way that mod_perl does
>>> {if you attach code to the right handlers/filters} meaning chopping in and
>>> changing code can be quite difficult in them.
>>>
>>> Both are good for simplish applications {yes and I've seen complex apps
>>> written in them as well - but they usually need a lot more hardware support
>>> than the equivalent mod_perl app to cope with demand}
>>>
>>> Unfortunately writing good mod_perl apps is hard - and so few mod_perl
>>> apps really make use of the underlying framework properly - effectively
>>> using it for code caching and not much else
>>>
>>>
>>>
>>> On 07/06/2018 19:24, David Hodgkinson wrote:
>>>
>>> Moving your method handlers to the framework.
>>>
>>> I like catalyst. Stand on the shoulders of giants. Mojolicious makes me
>>> itch.
>>>
>>> On 7 Jun 2018, at 19:21, John Dunlap <jo...@lariat.co> wrote:
>>>
>>> What is involved in porting an application from mod_perl to starman?
>>>
>>> Throwing away logic and logical structure and replacing it with a much
>>> less flexible approach...
>>>
>>> On Thu, Jun 7, 2018 at 6:18 PM, Clive Eisen <cl...@hildebrand.co.uk>
>>> wrote:
>>>
>>>> On 7 Jun 2018, at 19:13, David Hodgkinson <da...@gmail.com> wrote:
>>>>
>>>> No. Different concept.
>>>>
>>>> On 7 Jun 2018, at 18:52, John Dunlap <jo...@lariat.co> wrote:
>>>>
>>>> Is Plack backwards compatible with mod_perl?
>>>>
>>>> On Thu, Jun 7, 2018 at 5:44 PM, David Hodgkinson <da...@gmail.com>
>>>> wrote:
>>>>
>>>>> We’re all about the Plack these days.
>>>>>
>>>>>
>>>> This.
>>>>
>>>> We have moved entirely to
>>>>
>>>> nginx (doing the ssl where appropriate) -> starman (which uses plack)
>>>> and Dancer2
>>>>
>>>> Life is a LOT better
>>>>
>>>> —
>>>> Clive
>>>>
>>>>
>>>
>>>
>>> --
>>> John Dunlap
>>> *CTO | Lariat *
>>>
>>> *Direct:*
>>> *john@lariat.co <jo...@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
>>> <https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
>>>
>>>
>>
>>
>>
>> --
>> John Dunlap
>> *CTO | Lariat *
>>
>> *Direct:*
>> *john@lariat.co <jo...@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
>> <https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
>>
>>
>
>
--
John Dunlap
*CTO | Lariat *
*Direct:*
*john@lariat.co <jo...@lariat.co>*
*Customer Service:*
877.268.6667
support@lariat.co
Re: Future MPM Support? (...and future of mod_perl)
Posted by Randolf Richardson <ra...@modperl.pl>.
> On 30.07.2018 03:51, Paul B. Henson wrote:
> > On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
> >> Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
> >
> > Yep, me too; Plack is really not a feature equivilent replacement for
> > mod_perl :(.
> >
> +1.
> Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web application side, at
> different levels and in different ways.
And then there are CMS (Content Management System) solutions in
other languages like PHP that get a lot of attention too.
We have a very basic custom framework that we use for all of the
internet sites that we maintain, and we'd had to adapt it as new
versions of Apache HTTPd come along so as to keep up with changing
APIs. I suspect this isn't a unique problem to mod_perl though as
there seem to be major changes for those moving from PHP 5 to PHP 7
(as an example).
It would be great to see something like Modx written in mod_perl,
and also a good Wiki alternative to that commonly-used PHP one out
there, and I think there could be an opportunity there since both of
those seem to be locked in to a MySQL backend -- the opportunity
being additional support for other databases, namely PostgreSQL.
I also own the modperl.pl internet domain name, and I'm certainly
willing to set up a directory there of such projects if anyone's
interested.
I do wonder sometimes if one of the challenges is that Perl has not
had enough of its deserved visibility because many implementions
don't seem to use a .pl suffix on the URLs (I've made an effort to do
this on most of the sites I'm running that use Perl). With other
languages like PHP there's the .php suffix that's quite prevalent,
and there's also .jsp (Java Server Pages) and others, and these do
double as advertisements for their respective programming languages.
> But there is (to my knowledge) no equivalent for mod_perl's ability to interact deeply
> with the Apache internal Request processing logic.
> In that respect, comparing mod_perl to Plack etc is like comparing apples to pears : not
> very relevant.
I agree, and I use those features myself. ModPerl is very well
suited to developing other protocols as well, such as a TelNet server
(which may not be so great for Apache with regard to connection
limits), or a NICNAME/WHOIS server (which I've done), or a Finger
server, etc., which communicate over their respective raw protocols
and don't utilize HTTP/HTTPS at all.
> Considering that, for better or worse, Perl as a programming language does not seem to be
> really attractive to the current generation of software developers anymore, I would not
> really mind if some tool equivalent to mod_perl was developed using whichever other
> scripting language is currently more in fashion (javascript ? python ? ..), but it really
> seems a pity to "slowly abandon" mod_perl without providing some tool of equivalent power
> in terms of deep interaction with Apache httpd.
Although I'm helping my 10-year-old daughter learn Perl as her first
programming language, I have noticed that a lot of the post-secondary
schools are teaching Python.
I agree that it would be a pity to abandon mod_perl, full stop. I
also agree that it brings a lot of possibilities to Apache HTTPd that
other languages don't. If mod_perl were to be abandoned, that would
probably be a major setback for Apache HTTPd as well, but a lot of
people likely wouldn't notice, at least not for a long time.
If I had to abandon mod_perl/Perl, I would definitely want these
same capabilities to interject at various stages (and not just the
authentication stages), and if it wasn't there I'd probably just
write my own in Java or whatever is most useful to me at the time
(and I know I'd be re-inventing the wheel to an extent, but it would
probably be easier for me than writing an Apache HTTPd module in C).
On the plus side, I am finding that mod_perl works very well and
integrates seamlessly under Ubuntu Linux 18.04 LTS (64-bit). I have
been using mod_perl on NetBSD for approximately 2 decades now, and
that's been getting increasingly troublesome, so I sense that perhaps
the world transitioning over to Linux could qualify as something of a
parallel to what we're concerned about here with mod_perl's future.
Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/
Re: Future MPM Support?
Posted by Adam Prime <ad...@utoronto.ca>.
You should really throw a light weight server that can handle http 2 between your clients and your mod_perl machines. It’s not ideal in terms of maximizing what http 2 can do, but it can have a very significant impact.
Adam
> On Aug 4, 2018, at 9:08 PM, Michael A. Capone <mc...@cablewholesale.com> wrote:
>
> Yes, http/2 is our primary concern right now. At the moment, we've made the business decision to stay on mod_perl rather than migrate to another platform and gain http/2 benefits, but for how long can we maintain that decision? I'm honestly not sure.
>
> Now, we significantly under-utilize mod_perl, mostly doing CGI registry / code caching. Hey, if it was good 15 years ago, it's good today! :) But that does mean that there are potentially other options for us to explore, as we're not married to all the bells and whistles that mod_perl provides.
>
>> On 8/4/2018 5:47 AM, Paul Silevitch wrote:
>> Also issues with http/2 since it is not supported by prefork mpm anymore.
>>
>> On Wed, Aug 1, 2018 at 12:44 PM, John Dunlap <jo...@lariat.co> wrote:
>>> The biggest deficiency of mod_perl, at the moment, is that it cannot provide web sockets. In today's world, that's a huge problem.
>>>
>>> On Wed, Aug 1, 2018 at 11:30 AM, Robert Smith <sp...@wansecurity.com> wrote:
>>>> Who in the world would want to abandon mod_perl?
>>>>
>>>> What is this world coming to?
>>>>
>>>> -Robert
>>>>
>>>> > On Jul 30, 2018, at 5:44 PM, André Warnier (tomcat) <aw...@ice-sa.com> wrote:
>>>> >
>>>> > On 30.07.2018 03:51, Paul B. Henson wrote:
>>>> >> On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
>>>> >>> Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
>>>> >>
>>>> >> Yep, me too; Plack is really not a feature equivilent replacement for
>>>> >> mod_perl :(.
>>>> >>
>>>> > +1.
>>>> > Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web application side, at different levels and in different ways.
>>>> > But there is (to my knowledge) no equivalent for mod_perl's ability to interact deeply with the Apache internal Request processing logic.
>>>> > In that respect, comparing mod_perl to Plack etc is like comparing apples to pears : not very relevant.
>>>> > Considering that, for better or worse, Perl as a programming language does not seem to be really attractive to the current generation of software developers anymore, I would not really mind if some tool equivalent to mod_perl was developed using whichever other scripting language is currently more in fashion (javascript ? python ? ..), but it really seems a pity to "slowly abandon" mod_perl without providing some tool of equivalent power in terms of deep interaction with Apache httpd.
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> John Dunlap
>>> CTO | Lariat
>>>
>>> Direct:
>>> john@lariat.co
>>>
>>> Customer Service:
>>> 877.268.6667
>>> support@lariat.co
>>> <100x60.png>
>>
>
Re: Future MPM Support?
Posted by "Michael A. Capone" <mc...@cablewholesale.com>.
Yes, http/2 is our primary concern right now. At the moment, we've made
the business decision to stay on mod_perl rather than migrate to another
platform and gain http/2 benefits, but for how long can we maintain that
decision? I'm honestly not sure.
Now, we significantly under-utilize mod_perl, mostly doing CGI registry
/ code caching. Hey, if it was good 15 years ago, it's good today! :)
But that does mean that there are potentially other options for us to
explore, as we're not married to all the bells and whistles that
mod_perl provides.
On 8/4/2018 5:47 AM, Paul Silevitch wrote:
> Also issues with http/2 since it is not supported by prefork mpm anymore.
>
> On Wed, Aug 1, 2018 at 12:44 PM, John Dunlap <john@lariat.co
> <ma...@lariat.co>> wrote:
>
> The biggest deficiency of mod_perl, at the moment, is that it
> cannot provide web sockets. In today's world, that's a huge problem.
>
> On Wed, Aug 1, 2018 at 11:30 AM, Robert Smith
> <spamfree@wansecurity.com <ma...@wansecurity.com>> wrote:
>
> Who in the world would want to abandon mod_perl?
>
> What is this world coming to?
>
> -Robert
>
> > On Jul 30, 2018, at 5:44 PM, André Warnier (tomcat)
> <aw@ice-sa.com <ma...@ice-sa.com>> wrote:
> >
> > On 30.07.2018 03:51, Paul B. Henson wrote:
> >> On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
> >>> Like Dr. James Smith, I'm hooking into multiple handlers
> and using filters.
> >>
> >> Yep, me too; Plack is really not a feature equivilent
> replacement for
> >> mod_perl :(.
> >>
> > +1.
> > Plack and other frameworks (TT2, Moose, Catalyst, etc.)
> cover the web application side, at different levels and in
> different ways.
> > But there is (to my knowledge) no equivalent for mod_perl's
> ability to interact deeply with the Apache internal Request
> processing logic.
> > In that respect, comparing mod_perl to Plack etc is like
> comparing apples to pears : not very relevant.
> > Considering that, for better or worse, Perl as a programming
> language does not seem to be really attractive to the current
> generation of software developers anymore, I would not really
> mind if some tool equivalent to mod_perl was developed using
> whichever other scripting language is currently more in
> fashion (javascript ? python ? ..), but it really seems a pity
> to "slowly abandon" mod_perl without providing some tool of
> equivalent power in terms of deep interaction with Apache httpd.
> >
> >
> >
>
>
>
>
> --
> John Dunlap
> /CTO | Lariat/
> /
> /
> /*Direct:*/
> /john@lariat.co <ma...@lariat.co>/
> /
> *Customer Service:*/
> 877.268.6667
> support@lariat.co <ma...@lariat.co>
>
>
Re: Future MPM Support?
Posted by Paul Silevitch <pa...@silevitch.com>.
Also issues with http/2 since it is not supported by prefork mpm anymore.
On Wed, Aug 1, 2018 at 12:44 PM, John Dunlap <jo...@lariat.co> wrote:
> The biggest deficiency of mod_perl, at the moment, is that it cannot
> provide web sockets. In today's world, that's a huge problem.
>
> On Wed, Aug 1, 2018 at 11:30 AM, Robert Smith <sp...@wansecurity.com>
> wrote:
>
>> Who in the world would want to abandon mod_perl?
>>
>> What is this world coming to?
>>
>> -Robert
>>
>> > On Jul 30, 2018, at 5:44 PM, André Warnier (tomcat) <aw...@ice-sa.com>
>> wrote:
>> >
>> > On 30.07.2018 03:51, Paul B. Henson wrote:
>> >> On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
>> >>> Like Dr. James Smith, I'm hooking into multiple handlers and using
>> filters.
>> >>
>> >> Yep, me too; Plack is really not a feature equivilent replacement for
>> >> mod_perl :(.
>> >>
>> > +1.
>> > Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web
>> application side, at different levels and in different ways.
>> > But there is (to my knowledge) no equivalent for mod_perl's ability to
>> interact deeply with the Apache internal Request processing logic.
>> > In that respect, comparing mod_perl to Plack etc is like comparing
>> apples to pears : not very relevant.
>> > Considering that, for better or worse, Perl as a programming language
>> does not seem to be really attractive to the current generation of software
>> developers anymore, I would not really mind if some tool equivalent to
>> mod_perl was developed using whichever other scripting language is
>> currently more in fashion (javascript ? python ? ..), but it really seems a
>> pity to "slowly abandon" mod_perl without providing some tool of equivalent
>> power in terms of deep interaction with Apache httpd.
>> >
>> >
>> >
>>
>>
>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *john@lariat.co <jo...@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
>
Re: Future MPM Support?
Posted by John Dunlap <jo...@lariat.co>.
The biggest deficiency of mod_perl, at the moment, is that it cannot
provide web sockets. In today's world, that's a huge problem.
On Wed, Aug 1, 2018 at 11:30 AM, Robert Smith <sp...@wansecurity.com>
wrote:
> Who in the world would want to abandon mod_perl?
>
> What is this world coming to?
>
> -Robert
>
> > On Jul 30, 2018, at 5:44 PM, André Warnier (tomcat) <aw...@ice-sa.com>
> wrote:
> >
> > On 30.07.2018 03:51, Paul B. Henson wrote:
> >> On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
> >>> Like Dr. James Smith, I'm hooking into multiple handlers and using
> filters.
> >>
> >> Yep, me too; Plack is really not a feature equivilent replacement for
> >> mod_perl :(.
> >>
> > +1.
> > Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web
> application side, at different levels and in different ways.
> > But there is (to my knowledge) no equivalent for mod_perl's ability to
> interact deeply with the Apache internal Request processing logic.
> > In that respect, comparing mod_perl to Plack etc is like comparing
> apples to pears : not very relevant.
> > Considering that, for better or worse, Perl as a programming language
> does not seem to be really attractive to the current generation of software
> developers anymore, I would not really mind if some tool equivalent to
> mod_perl was developed using whichever other scripting language is
> currently more in fashion (javascript ? python ? ..), but it really seems a
> pity to "slowly abandon" mod_perl without providing some tool of equivalent
> power in terms of deep interaction with Apache httpd.
> >
> >
> >
>
>
--
John Dunlap
*CTO | Lariat *
*Direct:*
*john@lariat.co <jo...@lariat.co>*
*Customer Service:*
877.268.6667
support@lariat.co
Re: Future MPM Support?
Posted by Robert Smith <sp...@wansecurity.com>.
Who in the world would want to abandon mod_perl?
What is this world coming to?
-Robert
> On Jul 30, 2018, at 5:44 PM, André Warnier (tomcat) <aw...@ice-sa.com> wrote:
>
> On 30.07.2018 03:51, Paul B. Henson wrote:
>> On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
>>> Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
>>
>> Yep, me too; Plack is really not a feature equivilent replacement for
>> mod_perl :(.
>>
> +1.
> Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web application side, at different levels and in different ways.
> But there is (to my knowledge) no equivalent for mod_perl's ability to interact deeply with the Apache internal Request processing logic.
> In that respect, comparing mod_perl to Plack etc is like comparing apples to pears : not very relevant.
> Considering that, for better or worse, Perl as a programming language does not seem to be really attractive to the current generation of software developers anymore, I would not really mind if some tool equivalent to mod_perl was developed using whichever other scripting language is currently more in fashion (javascript ? python ? ..), but it really seems a pity to "slowly abandon" mod_perl without providing some tool of equivalent power in terms of deep interaction with Apache httpd.
>
>
>
Re: Future MPM Support?
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 30.07.2018 03:51, Paul B. Henson wrote:
> On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
>> Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
>
> Yep, me too; Plack is really not a feature equivilent replacement for
> mod_perl :(.
>
+1.
Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web application side, at
different levels and in different ways.
But there is (to my knowledge) no equivalent for mod_perl's ability to interact deeply
with the Apache internal Request processing logic.
In that respect, comparing mod_perl to Plack etc is like comparing apples to pears : not
very relevant.
Considering that, for better or worse, Perl as a programming language does not seem to be
really attractive to the current generation of software developers anymore, I would not
really mind if some tool equivalent to mod_perl was developed using whichever other
scripting language is currently more in fashion (javascript ? python ? ..), but it really
seems a pity to "slowly abandon" mod_perl without providing some tool of equivalent power
in terms of deep interaction with Apache httpd.
Re: Future MPM Support?
Posted by "Paul B. Henson" <he...@acm.org>.
On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
> Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
Yep, me too; Plack is really not a feature equivilent replacement for
mod_perl :(.