Re: Enquiry about mod_perl project state

[Michael Schout]

On 8/14/15 9:59 AM, John Dunlap wrote:
> mod_perl isn't the cool kid on the block anymore but there are a lot
> of systems out there built on top of it and I doubt it's going away
> any time soon.
I'd have to agree with this sentiment largely.  Yes, its not the cool
kid on the block like it was 15 years ago, but its still alive and still
gets the job done. Speaking from my own experience, I still have clients
that have large legacy mod_perl apps and those apps are not going away
any time soon.  

But personally I tend to go with a Plack/PSGI based solution for new
projects.  I suspect a lot of other people are doing the same thing. 
You can still run these projects under Apache/mod_perl.  Or, you can run
them under a pile of other systems (personally I like nginx in front of
starman, but to each their own).

As far as migration path, it depends how deeply the tentacles of your
application have dug into the Apache API.  I have migrated a few
projects off of mod_perl that were very easy, and a few that required
extensive changes in order to run under PSGI.

But I have no problems/fears about the state of mod_perl at this point. 
The port to Apache 2.4 has taken a while, but that is understandable
given the massive changes to the internal apache API.  Simply upgrading
your legacy apps to Apache 2.4+mod_perl alone is going to require some
work because the API has changed. 

Cheers!
Michael Schout

Re: Enquiry about mod_perl project state

[Kevin A. McGrail]

On 9/2/2015 6:16 AM, Vincent Veyron wrote:

On Tue, 1 Sep 2015 16:45:47 -0500
Igor Chudov  wrote:


I make many thousands of $$$ per month from my websites, all of which are
based on mod_perl. I wrote everything myself.
  

Do you think that if Apache makes some big changes, mod_perl will follow?


It will probably follow, and in case it does not, all you will have to do is 
direct a fraction of those many thousands of $$$ toward a developper that will 
make the necessary changes for you (and the community).

That's what I plan to do anyway, with the caveat that my site does not generate 
many thousands of $$$ yet (but I'm hopeful).
A great point, Vincent, because I agree that is the true beauty of open 
source in a capitalist endeavor.  There is no vendor to go out of 
business.  You have the source code and there are plenty of talented 
developers looking to feed their kids.  We hope you'll contribute back 
to the community and keep the whole wheel turning!


Regards,
KAM

Re: Enquiry about mod_perl project state

[Vincent Veyron]

On Tue, 1 Sep 2015 16:45:47 -0500
Igor Chudov  wrote:

> I make many thousands of $$$ per month from my websites, all of which are
> based on mod_perl. I wrote everything myself.
 
> Do you think that if Apache makes some big changes, mod_perl will follow?
> 

It will probably follow, and in case it does not, all you will have to do is 
direct a fraction of those many thousands of $$$ toward a developper that will 
make the necessary changes for you (and the community).

That's what I plan to do anyway, with the caveat that my site does not generate 
many thousands of $$$ yet (but I'm hopeful).



-- 
Salutations, Vincent Veyron 

https://legalcase.libremen.com/ 
Legal case, contract and insurance claim management software

Re: Enquiry about mod_perl project state

[Randal L. Schwartz]

> "James" == James Smith  writes:

James> I have watched a number of projects move away from mod_perl -
James> often to Dancer/ Catalyst etc and then they ask can I do X, Y or
James> Z...

That's one thing people overlook about mod_perl... it really can
customize *any* of the 14 phases... most of the other frameworks are
content-phase only, or some limited insertion into the other phases.

Hmm.  14 sounds too small.  I think that was for apache 1.x.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

Re: Enquiry about mod_perl project state

[Igor Chudov]

I make many thousands of $$$ per month from my websites, all of which are
based on mod_perl. I wrote everything myself.

Rewriting them would be undesirable and very cost prohibitive.

I have no real need for any "evolution" and "continued development" of
mod_perl, which I consider to be as perfect as things get. All I want is
for mod_perl to continue working with evolving apache, so:

Do you think that if Apache makes some big changes, mod_perl will follow?

I have a huge money at stake here and my family well being depends sorely
on mod_perl's reliable existence.


On Tue, Sep 1, 2015 at 3:06 PM, Randal L. Schwartz 
wrote:

> > "James" == James Smith  writes:
>
> James> I have watched a number of projects move away from mod_perl -
> James> often to Dancer/ Catalyst etc and then they ask can I do X, Y or
> James> Z...
>
> That's one thing people overlook about mod_perl... it really can
> customize *any* of the 14 phases... most of the other frameworks are
> content-phase only, or some limited insertion into the other phases.
>
> Hmm.  14 sounds too small.  I think that was for apache 1.x.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
> 0095
>  
> Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> Still trying to think of something clever for the fourth line of this .sig
>

[Rusonyx #1410913]: RE: Enquiry about mod_perl project state

[Rusonyx Support Team]

Dami Laurent (PJ),

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1410913
Тема: RE: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: Enquiry about mod_perl project state

[John Dunlap]

Our application is in a state of transition from dynamically generating
html on the server to providing restful web services which are consumed by
a JavaScript user interface in a service oriented front end architecture.
However, when we decided that that was the road we needed to go down, none
of the existing perl web frameworks fit our needs so we ended up building
our own web service framework from scratch. My only limitation with
mod_perl is the lack of web socket support but that is easy to work around
with infrastructure as a service offerings like PubNub.
On Aug 18, 2015 7:42 PM, Fred Moyer f...@redhotpenguin.com wrote:

  I know of a lot of shops out there still running mod_perl. I'd say
 the focus has narrowed to web services that need to be really
 performant. There's a ton of web application frameworks out there, and
 those that are written in Perl can be served by mod_perl via Plack,
 etc.

 It's more of an API into the Apache http request cycle now than
 something that directly serves up websites. Which is initially what it
 started out as :)

 On Sat, Aug 15, 2015 at 9:34 AM, Randolf Richardson rand...@modperl.pl
 wrote:
  (This reply to Dr. James Smith's message is also intended for
 Ashish
  Mukherjee...)
 
  You're hooking in to more handlers than I typically do -- I hook
  into PerlAuthenHandler and PerlAuthzHandler (to implement a custom
  login system I created that uses one cookie, so it's been great that
  cookies are accessible at these stages), so that's two places (I
  found that I have to set up handlers for both or else neither works,
  which is fine because simply returning Apache2::Const::OK for authz
  is trivially easy).
 
  In my test environments, I use PerlInitHandler with
 Apache2::Reload,
  which I find does come with a slight performance hit, but that's okay
  because they're not as busy as the production environments.
 
  So, aside from that I use PerlRequire to load my main module
 (which
  includes the authen and authz handlers), and then I use the
  following stanza in a VirtualHost container in httpd.conf to handle
  all .pl files with mod_perl:
 
FilesMatch (\.p[lm]|^[^\.]+)$
  SetHandler modperl
  PerlOptions +SetupEnv
  PerlResponseHandler ModPerl::Registry
  AddOutputFilter INCLUDES .pl
  Options +Includes +ExecCGI
/FilesMatch
 
  My main Perl module, at the authen() stage, connects to
 PostgreSQL
  with DBI using connect_cached, and then stores a referenced to itself
  with $r-pnotes, which is later used by all the .pl files in my web
  sites to use the same database connection (why waste CPU resources by
  reconnecting and re-processing the cookie twice when we can just
  re-use what's already been established in the authen() stage?).
 
  One of the nice things about using the pnotes mechanism is that
 it
  also means that I can write my .pl files in a generic manner so that
  they can easily be copied to other web sites that use different main
  modules (as long as I support the same functions for generating
  headers and footers, and other web site styling, which I do).
 
  For me, mod_perl has been an amazing productivity tool, and I've
  been building nearly all my web sites with it (where I don't use
  mod_perl is when all I need is plain HTML without any server-side
  functionality).  One of the greatest things about using mod_perl is
  the consistently high performance it provides, even when enduring
  heavy traffic loads (there are limits, of course, but comparatively I
  find that mod_perl handles a lot more traffic than many other systems
  like PHP, and so hardware infrastructure costs are less overall too).
 
  I agree with Randolf,
 
  I have watched a number of projects move away from mod_perl - often to
  Dancer/
  Catalyst etc and then they ask can I do X, Y or Z...
 
  I say if you were using mod_perl you could do that easily but usually
  find the tool chain for
  doing something similar in Dancer or Catalyst is infinitely more
  complex, because you can't
  simply add a handler here or an output filter there. You can do this
  with chained middleware
  in Dancer but it is not that easy to implement...
 
  The main thing with mod_perl is - as long as Apache doesn't mess around
  with the core HTTPD
  interface (like they did with 2.4) then there isn't anything much that
  needs changing - because
  it is good solid and just works... If it ain't broke then it doesn't
  need changing.
 
  I probably use more pure mod_perl - no registry scripts here thank
  you! - and hook into the
  apache process at about 7- 8 places to handle users, templating,
  diagnostics, optimisation etc
 
  On 14/08/2015 18:51, Randolf Richardson wrote:
   Hello,
  
   I wanted to enquire about the status of mod_perl, since there is
 largely an
   impression it is end of life. The project site also does not say
 much. I
   see many of the mod_perl shops now moving to perl 

[Rusonyx #1410835]: Re: Enquiry about mod_perl project state

[Rusonyx Support Team]

John Dunlap,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1410835
Тема: Re: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: Enquiry about mod_perl project state

[Fred Moyer]

 I know of a lot of shops out there still running mod_perl. I'd say
the focus has narrowed to web services that need to be really
performant. There's a ton of web application frameworks out there, and
those that are written in Perl can be served by mod_perl via Plack,
etc.

It's more of an API into the Apache http request cycle now than
something that directly serves up websites. Which is initially what it
started out as :)

On Sat, Aug 15, 2015 at 9:34 AM, Randolf Richardson rand...@modperl.pl wrote:
 (This reply to Dr. James Smith's message is also intended for Ashish
 Mukherjee...)

 You're hooking in to more handlers than I typically do -- I hook
 into PerlAuthenHandler and PerlAuthzHandler (to implement a custom
 login system I created that uses one cookie, so it's been great that
 cookies are accessible at these stages), so that's two places (I
 found that I have to set up handlers for both or else neither works,
 which is fine because simply returning Apache2::Const::OK for authz
 is trivially easy).

 In my test environments, I use PerlInitHandler with Apache2::Reload,
 which I find does come with a slight performance hit, but that's okay
 because they're not as busy as the production environments.

 So, aside from that I use PerlRequire to load my main module (which
 includes the authen and authz handlers), and then I use the
 following stanza in a VirtualHost container in httpd.conf to handle
 all .pl files with mod_perl:

   FilesMatch (\.p[lm]|^[^\.]+)$
 SetHandler modperl
 PerlOptions +SetupEnv
 PerlResponseHandler ModPerl::Registry
 AddOutputFilter INCLUDES .pl
 Options +Includes +ExecCGI
   /FilesMatch

 My main Perl module, at the authen() stage, connects to PostgreSQL
 with DBI using connect_cached, and then stores a referenced to itself
 with $r-pnotes, which is later used by all the .pl files in my web
 sites to use the same database connection (why waste CPU resources by
 reconnecting and re-processing the cookie twice when we can just
 re-use what's already been established in the authen() stage?).

 One of the nice things about using the pnotes mechanism is that it
 also means that I can write my .pl files in a generic manner so that
 they can easily be copied to other web sites that use different main
 modules (as long as I support the same functions for generating
 headers and footers, and other web site styling, which I do).

 For me, mod_perl has been an amazing productivity tool, and I've
 been building nearly all my web sites with it (where I don't use
 mod_perl is when all I need is plain HTML without any server-side
 functionality).  One of the greatest things about using mod_perl is
 the consistently high performance it provides, even when enduring
 heavy traffic loads (there are limits, of course, but comparatively I
 find that mod_perl handles a lot more traffic than many other systems
 like PHP, and so hardware infrastructure costs are less overall too).

 I agree with Randolf,

 I have watched a number of projects move away from mod_perl - often to
 Dancer/
 Catalyst etc and then they ask can I do X, Y or Z...

 I say if you were using mod_perl you could do that easily but usually
 find the tool chain for
 doing something similar in Dancer or Catalyst is infinitely more
 complex, because you can't
 simply add a handler here or an output filter there. You can do this
 with chained middleware
 in Dancer but it is not that easy to implement...

 The main thing with mod_perl is - as long as Apache doesn't mess around
 with the core HTTPD
 interface (like they did with 2.4) then there isn't anything much that
 needs changing - because
 it is good solid and just works... If it ain't broke then it doesn't
 need changing.

 I probably use more pure mod_perl - no registry scripts here thank
 you! - and hook into the
 apache process at about 7- 8 places to handle users, templating,
 diagnostics, optimisation etc

 On 14/08/2015 18:51, Randolf Richardson wrote:
  Hello,
 
  I wanted to enquire about the status of mod_perl, since there is largely 
  an
  impression it is end of life. The project site also does not say much. I
  see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
  or going the Java way.
  I'm still using mod_perl to develop new web sites.  The most recent
  one I've published is called the atheist Blog Roll and it uses a
  PostgreSQL database in the back-end:
 
  http://www.atheistblogroll.com/
 
  There are other projects on my horizon that continue to be developed
  in mod_perl, and they range from simple web sites to fully
  interactive projects.
 
  When there is a need for a client-side application, I use Java
  because I only have to write the code once to gain support on
  multiple Operating Systems (e.g., Unix/Linux, Windows, MacOS), and if
  it needs to interact with a web site, then I typically use mod_perl
  for that end of things.
 
  

[Rusonyx #1410832]: Re: Enquiry about mod_perl project state

[Rusonyx Support Team]

Fred Moyer,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1410832
Тема: Re: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: [Rusonyx #1410025]: Re: Enquiry about mod_perl project state

[André Warnier]

Hi.

Isn't anyone going to do anything about (kindly) this Russian auto-responder ?
Like, unsubscribe it from the list ?


Rusonyx Support Team wrote:

Randolf Richardson,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1410025
Тема: Re: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 


Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: [Rusonyx #1410025]: Re: Enquiry about mod_perl project state

[John D Groenveld]

In message 55cf7eb6.2050...@ice-sa.com, =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= writ
es:
Isn't anyone going to do anything about (kindly) this Russian auto-responder ?
Like, unsubscribe it from the list ?

I sent a note modperl-owner in case he's not reading mailing list.

John
groenv...@acm.org

[Rusonyx #1410006]: Re: Enquiry about mod_perl project state

[Rusonyx Support Team]

Dr James Smith,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1410006
Тема: Re: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: Enquiry about mod_perl project state

[Dr James Smith]

I agree with Randolf,

I have watched a number of projects move away from mod_perl - often to 
Dancer/

Catalyst etc and then they ask can I do X, Y or Z...

I say if you were using mod_perl you could do that easily but usually 
find the tool chain for
doing something similar in Dancer or Catalyst is infinitely more 
complex, because you can't
simply add a handler here or an output filter there. You can do this 
with chained middleware

in Dancer but it is not that easy to implement...

The main thing with mod_perl is - as long as Apache doesn't mess around 
with the core HTTPD
interface (like they did with 2.4) then there isn't anything much that 
needs changing - because
it is good solid and just works... If it ain't broke then it doesn't 
need changing.


I probably use more pure mod_perl - no registry scripts here thank 
you! - and hook into the
apache process at about 7- 8 places to handle users, templating, 
diagnostics, optimisation etc


On 14/08/2015 18:51, Randolf Richardson wrote:

Hello,

I wanted to enquire about the status of mod_perl, since there is largely an
impression it is end of life. The project site also does not say much. I
see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
or going the Java way.

I'm still using mod_perl to develop new web sites.  The most recent
one I've published is called the atheist Blog Roll and it uses a
PostgreSQL database in the back-end:

http://www.atheistblogroll.com/

There are other projects on my horizon that continue to be developed
in mod_perl, and they range from simple web sites to fully
interactive projects.

When there is a need for a client-side application, I use Java
because I only have to write the code once to gain support on
multiple Operating Systems (e.g., Unix/Linux, Windows, MacOS), and if
it needs to interact with a web site, then I typically use mod_perl
for that end of things.

For one of the projects I'm working on (which is not ready for
public consumption quite yet), I've also written a WHOIS server using
mod_perl (which listens on TCP port 43, and responds to queries based
on its findings in PostgreSQL) to facilitate public membership record
lookups (only for the portions that will be publicly accessible).


What is the future of mod_perl beyond mod_perl 2.0? What is the upgrade
path recommended by the mod_perl veterans?

When I upgrade, I'm normally installing new server hardware and so I
migrate sites over one at a time, and resolve any API change
requirements before promoting the new server to production (followed
by log file merges after switching servers and traffic to the old
servers cease).


Regards,
Ashish

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer  Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/






--
The Wellcome Trust 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: Enquiry about mod_perl project state

[Randolf Richardson]

(This reply to Dr. James Smith's message is also intended for Ashish 
Mukherjee...)

You're hooking in to more handlers than I typically do -- I hook 
into PerlAuthenHandler and PerlAuthzHandler (to implement a custom 
login system I created that uses one cookie, so it's been great that 
cookies are accessible at these stages), so that's two places (I 
found that I have to set up handlers for both or else neither works, 
which is fine because simply returning Apache2::Const::OK for authz 
is trivially easy).

In my test environments, I use PerlInitHandler with Apache2::Reload, 
which I find does come with a slight performance hit, but that's okay 
because they're not as busy as the production environments.

So, aside from that I use PerlRequire to load my main module (which 
includes the authen and authz handlers), and then I use the 
following stanza in a VirtualHost container in httpd.conf to handle 
all .pl files with mod_perl:

  FilesMatch (\.p[lm]|^[^\.]+)$
SetHandler modperl
PerlOptions +SetupEnv
PerlResponseHandler ModPerl::Registry
AddOutputFilter INCLUDES .pl
Options +Includes +ExecCGI
  /FilesMatch

My main Perl module, at the authen() stage, connects to PostgreSQL 
with DBI using connect_cached, and then stores a referenced to itself 
with $r-pnotes, which is later used by all the .pl files in my web 
sites to use the same database connection (why waste CPU resources by 
reconnecting and re-processing the cookie twice when we can just 
re-use what's already been established in the authen() stage?).

One of the nice things about using the pnotes mechanism is that it 
also means that I can write my .pl files in a generic manner so that 
they can easily be copied to other web sites that use different main 
modules (as long as I support the same functions for generating 
headers and footers, and other web site styling, which I do).

For me, mod_perl has been an amazing productivity tool, and I've 
been building nearly all my web sites with it (where I don't use 
mod_perl is when all I need is plain HTML without any server-side 
functionality).  One of the greatest things about using mod_perl is 
the consistently high performance it provides, even when enduring 
heavy traffic loads (there are limits, of course, but comparatively I 
find that mod_perl handles a lot more traffic than many other systems 
like PHP, and so hardware infrastructure costs are less overall too).

 I agree with Randolf,
 
 I have watched a number of projects move away from mod_perl - often to 
 Dancer/
 Catalyst etc and then they ask can I do X, Y or Z...
 
 I say if you were using mod_perl you could do that easily but usually 
 find the tool chain for
 doing something similar in Dancer or Catalyst is infinitely more 
 complex, because you can't
 simply add a handler here or an output filter there. You can do this 
 with chained middleware
 in Dancer but it is not that easy to implement...
 
 The main thing with mod_perl is - as long as Apache doesn't mess around 
 with the core HTTPD
 interface (like they did with 2.4) then there isn't anything much that 
 needs changing - because
 it is good solid and just works... If it ain't broke then it doesn't 
 need changing.
 
 I probably use more pure mod_perl - no registry scripts here thank 
 you! - and hook into the
 apache process at about 7- 8 places to handle users, templating, 
 diagnostics, optimisation etc
 
 On 14/08/2015 18:51, Randolf Richardson wrote:
  Hello,
 
  I wanted to enquire about the status of mod_perl, since there is largely an
  impression it is end of life. The project site also does not say much. I
  see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
  or going the Java way.
  I'm still using mod_perl to develop new web sites.  The most recent
  one I've published is called the atheist Blog Roll and it uses a
  PostgreSQL database in the back-end:
 
  http://www.atheistblogroll.com/
 
  There are other projects on my horizon that continue to be developed
  in mod_perl, and they range from simple web sites to fully
  interactive projects.
 
  When there is a need for a client-side application, I use Java
  because I only have to write the code once to gain support on
  multiple Operating Systems (e.g., Unix/Linux, Windows, MacOS), and if
  it needs to interact with a web site, then I typically use mod_perl
  for that end of things.
 
  For one of the projects I'm working on (which is not ready for
  public consumption quite yet), I've also written a WHOIS server using
  mod_perl (which listens on TCP port 43, and responds to queries based
  on its findings in PostgreSQL) to facilitate public membership record
  lookups (only for the portions that will be publicly accessible).
 
  What is the future of mod_perl beyond mod_perl 2.0? What is the upgrade
  path recommended by the mod_perl veterans?
  When I upgrade, I'm normally 

[Rusonyx #1410025]: Re: Enquiry about mod_perl project state

[Rusonyx Support Team]

Randolf Richardson,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1410025
Тема: Re: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Enquiry about mod_perl project state

[Ashish Mukherjee]

Hello,

I wanted to enquire about the status of mod_perl, since there is largely an
impression it is end of life. The project site also does not say much. I
see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
or going the Java way.

What is the future of mod_perl beyond mod_perl 2.0? What is the upgrade
path recommended by the mod_perl veterans?

Regards,
Ashish

[Rusonyx #1409767]: Enquiry about mod_perl project state

[Rusonyx Support Team]

Ashish Mukherjee,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1409767
Тема: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: Enquiry about mod_perl project state

[John Dunlap]

mod_perl isn't the cool kid on the block anymore but there are a lot of
systems out there built on top of it and I doubt it's going away any time
soon.

On Fri, Aug 14, 2015 at 5:24 AM, Ashish Mukherjee 
ashish.mukher...@gmail.com wrote:

 Hello,

 I wanted to enquire about the status of mod_perl, since there is largely
 an impression it is end of life. The project site also does not say much. I
 see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
 or going the Java way.

 What is the future of mod_perl beyond mod_perl 2.0? What is the upgrade
 path recommended by the mod_perl veterans?

 Regards,
 Ashish




-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co j...@lariat.co*

*Customer Service:*
877.268.6667
supp...@lariat.co

[Rusonyx #1409867]: Re: Enquiry about mod_perl project state

[Rusonyx Support Team]

John Dunlap,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1409867
Тема: Re: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: Enquiry about mod_perl project state

[Ruben Safir]

On 08/14/2015 10:59 AM, John Dunlap wrote:
 mod_perl isn't the cool kid on the block anymore but there are a lot of
 systems out there built on top of it and I doubt it's going away any time
 soon.
 
 On Fri, Aug 14, 2015 at 5:24 AM, Ashish Mukherjee 
 ashish.mukher...@gmail.com wrote:
 
 Hello,

 I wanted to enquire about the status of mod_perl, since there is largely
 an impression it is end of life. The project site also does not say much. I
 see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
 or going the Java way.

 What is the future of mod_perl beyond mod_perl 2.0? What is the upgrade
 path recommended by the mod_perl veterans?

 Regards,
 Ashish

 
 
 


isn't there a mod_perl 2.2

mod_perl is not going anywhere.  It is far to useful.

[Rusonyx #1409870]: Re: Enquiry about mod_perl project state

[Rusonyx Support Team]

Ruben Safir,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1409870
Тема: Re: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: Enquiry about mod_perl project state

[Randolf Richardson]

 Hello,
 
 I wanted to enquire about the status of mod_perl, since there is largely an
 impression it is end of life. The project site also does not say much. I
 see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
 or going the Java way.

I'm still using mod_perl to develop new web sites.  The most recent 
one I've published is called the atheist Blog Roll and it uses a 
PostgreSQL database in the back-end:

http://www.atheistblogroll.com/

There are other projects on my horizon that continue to be developed 
in mod_perl, and they range from simple web sites to fully 
interactive projects.

When there is a need for a client-side application, I use Java 
because I only have to write the code once to gain support on 
multiple Operating Systems (e.g., Unix/Linux, Windows, MacOS), and if 
it needs to interact with a web site, then I typically use mod_perl 
for that end of things.

For one of the projects I'm working on (which is not ready for 
public consumption quite yet), I've also written a WHOIS server using 
mod_perl (which listens on TCP port 43, and responds to queries based 
on its findings in PostgreSQL) to facilitate public membership record 
lookups (only for the portions that will be publicly accessible).

 What is the future of mod_perl beyond mod_perl 2.0? What is the upgrade
 path recommended by the mod_perl veterans?

When I upgrade, I'm normally installing new server hardware and so I 
migrate sites over one at a time, and resolve any API change 
requirements before promoting the new server to production (followed 
by log file merges after switching servers and traffic to the old 
servers cease).

 Regards,
 Ashish

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer  Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

[Rusonyx #1409891]: Re: Enquiry about mod_perl project state

[Rusonyx Support Team]

Randolf Richardson,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1409891
Тема: Re: Enquiry about mod_perl project state
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: [Rusonyx #1409891]: Re: Enquiry about mod_perl project state

[Alexandr Evstigneev]

Please, remove russian ISP address (supp...@rusonyx.ru) from the thread.

14 августа 2015 г., 20:52 пользователь Rusonyx Support Team 
supp...@rusonyx.ru написал:

 Randolf Richardson,

 Вы написали в компанию Русоникс и это письмо является автоматическим
 подтверждением того, что Ваша заявка поступила в очередь на обработку.
 Мы ответим на Ваш запрос по возможности максимально быстро.

 ID Заявки: 1409891
 Тема: Re: Enquiry about mod_perl project state
 Отдел: Support
 Тип: Issue
 Статус: Open
 Приоритет: Medium
 С уважением
 ООО Русоникс
 www.rusonyx.ru

 Rusonyx


 --
 Портал технической поддержки: https://support.rusonyx.ru/index.php?