Mailing List Archive

The problem is I don't think there is mod_perl is quite a unique infrastructure - across all language I believe! I don't think any other language/framework gives you this level of flexibility.

Most frameworks just concentrate on the request phase and shoe horn everything in there - so you can't mix and match which technologies you use for different parts of the release cycle.

I looked at rewriting our framework in PSGI - dancer - and although it is possible we would have had to throw away 50% of the ultra-cool features or implement a fake request cycle with the request phase {to mimic what most dancer developers do anyway} but then putting the configurable logic in would add a whole new issue - apache has this nice config framework all setup you can use.

The other bit that as missing was the non-Perl part to be able to have different parts of the process handled by different languages (even the response phase)

-----Original Message-----
From: Jim Albert <jim@netrition.com>
Sent: 18 March 2021 04:01
To: modperl@perl.apache.org
Subject: mod_perl alternatives [EXT]

Given the recent discussion on the need for mod_perl PMC members and the disclosure that there is no active development on mod_perl this seems like an appropriate time to start a thread on a discussion of mod_perl alternatives inline with the various means of using mod_perl from the low level use of interfacing with the Apache server to the quick and dirty stuff (ModPerl::PerlRun, I believe to keep Perl and modules in memory).

I've seen mod_fcgid proposed in posts on other forums. Has anyone played with alternatives? I expect the low level Apache interaction might be difficult to duplicate at least to continue to do so in Perl. Perhaps the ModPerl::PerlRun approach of keeping Perl and modules in memory is a potential starting point for discussion for those using mod_perl at the most basic level.

Jim






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

I don't think there's any sudden urgency to switch to something else, since
nothing has actually changed about the state of mod_perl. However, if you
do want to migrate to something else, you should look at Plack:
https://metacpan.org/pod/Plack

Plack is not a drop-in replacement for mod_perl, but it's a high-quality
project with a well-developed ecosystem that will have some sort of
solution for most (not all) things that people are doing in mod_perl. But
again, I don't think you need to rush to do anything here.

- Perrin

On Thu, Mar 18, 2021 at 12:01 AM Jim Albert <jim@netrition.com> wrote:

> Given the recent discussion on the need for mod_perl PMC members and the
> disclosure that there is no active development on mod_perl this seems
> like an appropriate time to start a thread on a discussion of mod_perl
> alternatives inline with the various means of using mod_perl from the
> low level use of interfacing with the Apache server to the quick and
> dirty stuff (ModPerl::PerlRun, I believe to keep Perl and modules in
> memory).
>
> I've seen mod_fcgid proposed in posts on other forums. Has anyone played
> with alternatives? I expect the low level Apache interaction might be
> difficult to duplicate at least to continue to do so in Perl. Perhaps
> the ModPerl::PerlRun approach of keeping Perl and modules in memory is a
> potential starting point for discussion for those using mod_perl at the
> most basic level.
>
> Jim
>
>
>
>