Mailing List Archive

Alternatives to CGI perl module
I hope that this message would not be considered off topic.

I have been developing web apps since 1996 and have about 84,000 lines of
perl code implementing various websites that I own. I do not work for
anybody, own all websites that I work on, and these sites feed my family.

The largest website is www.algebra.com and I have plenty of other websites,
some to be used inside my own company, and some niche websites like
liberatedmanuals.com. All these sites work, and all use the CGI perl
module.

I always considered the CGI perl module to be a work of a genius. How it
does forms, prefilling of form values, working with arguments, headers,
cookies, html generation and so on were outstanding. The criticism of CGI
as far as importing HTML generating functions in the main namespace is
valid, but can be answered in a simple way, do not use the functionality if
you do not like it (which is what I do), and use templates in your own code
when necessary (as I do).

OK, so now, as of ubuntu 16.04, CGI is considered obsolete and is being
phased out. I cannot change it. I am literally freaking out for two
reasons, one is that I have 84,000 lines of code using it, and another is
that I have hard times finding a suitable alternative.

One concern is that I want any alternatives to be maintained for the next
20 years. I can start using something new now if I can find a suitable
system. I read CGI::Alternatives and I am left with a feeling that none of
these will survive for 20 years. Second, while templating is important for
any big consumer facing websites, it is not necessary for intranet and
niche websites and makes things difficult to maintain. Additionally,
templating involves more than just HTML templates and sometimes needs to be
done in perl scripts, using perl functions to generate HTML as part of
templating, not just HTML files.

So, I am looking for some web app framework that is sensible, has good
support going forward and lets people use it "the easy way" (without a
bazillion of files supporting a simple script) or the "hard way" (with
templates etc). I want a module where HTML can be expressed as a perl
statement.

Are these any realistically good modules made for people such as myself?

thanks
Re: Alternatives to CGI perl module [ In reply to ]
On Sat, Sep 10, 2016 at 7:54 AM, Igor Chudov <ichudov@gmail.com> wrote:
> I hope that this message would not be considered off topic.
...

> I always considered the CGI perl module to be a work of a genius. How it

I agree, and use it, too.

...
> OK, so now, as of ubuntu 16.04, CGI is considered obsolete and is being
> phased out. I cannot change it. I am literally freaking out for two reasons,

Igor, why can't you install CGI yourself? It's still available on
CPAN.org. Also, I would use another distro if I were you. I moved
back to Debian years ago.


Best regards,

-Tom
Re: Alternatives to CGI perl module [ In reply to ]
Tom, thanks for your kind words.

I can, and will of course, install CGI myself as all my sites use it and I
have 84,000 lines written using it.

My concern is that it will break at some point going forward if it is not
maintained.

I try to use CGI.pm in ways that are not questionable, such as using it in
object oriented manner without importing its functions into my main
namespace.

Going forward, I think, I should get the message and switch to something
new that will be maintained -- but to what?

On Sat, Sep 10, 2016 at 7:54 AM, Igor Chudov <ichudov@gmail.com> wrote:

> I hope that this message would not be considered off topic.
>
> I have been developing web apps since 1996 and have about 84,000 lines of
> perl code implementing various websites that I own. I do not work for
> anybody, own all websites that I work on, and these sites feed my family.
>
> The largest website is www.algebra.com and I have plenty of other
> websites, some to be used inside my own company, and some niche websites
> like liberatedmanuals.com. All these sites work, and all use the CGI perl
> module.
>
> I always considered the CGI perl module to be a work of a genius. How it
> does forms, prefilling of form values, working with arguments, headers,
> cookies, html generation and so on were outstanding. The criticism of CGI
> as far as importing HTML generating functions in the main namespace is
> valid, but can be answered in a simple way, do not use the functionality if
> you do not like it (which is what I do), and use templates in your own code
> when necessary (as I do).
>
> OK, so now, as of ubuntu 16.04, CGI is considered obsolete and is being
> phased out. I cannot change it. I am literally freaking out for two
> reasons, one is that I have 84,000 lines of code using it, and another is
> that I have hard times finding a suitable alternative.
>
> One concern is that I want any alternatives to be maintained for the next
> 20 years. I can start using something new now if I can find a suitable
> system. I read CGI::Alternatives and I am left with a feeling that none of
> these will survive for 20 years. Second, while templating is important for
> any big consumer facing websites, it is not necessary for intranet and
> niche websites and makes things difficult to maintain. Additionally,
> templating involves more than just HTML templates and sometimes needs to be
> done in perl scripts, using perl functions to generate HTML as part of
> templating, not just HTML files.
>
> So, I am looking for some web app framework that is sensible, has good
> support going forward and lets people use it "the easy way" (without a
> bazillion of files supporting a simple script) or the "hard way" (with
> templates etc). I want a module where HTML can be expressed as a perl
> statement.
>
> Are these any realistically good modules made for people such as myself?
>
> thanks
>
Re: Alternatives to CGI perl module [ In reply to ]
On Sat, Sep 10, 2016 at 08:18:53AM -0500, Igor Chudov wrote:
> Tom, thanks for your kind words.
>
> I can, and will of course, install CGI myself as all my sites use it and I
> have 84,000 lines written using it.
>
> My concern is that it will break at some point going forward if it is not
> maintained.
>
> I try to use CGI.pm in ways that are not questionable, such as using it in
> object oriented manner without importing its functions into my main
> namespace.
>
> Going forward, I think, I should get the message and switch to something
> new that will be maintained -- but to what?

CGI is being maintained, and very well, by Lee Johnson. You write:

> > OK, so now, as of ubuntu 16.04, CGI is considered obsolete and is being
> > phased out.

Considered obsolete by whom? By Ubuntu? Why do you think that? CGI.pm
is no longer in the perl core, but that makes it neither obsolete nor
unmaintained.

It is true that experienced Perl developers won't recommend CGI.pm for
new development work. But that doesn't mean that you need to migrate
your work away from CGI.pm. You might choose to do that anyway, to get
the benefits of more modern tools, but there are no plans to leave
CGI.pm unsupported.

> > Are these any realistically good modules made for people such as myself?

If you do choose to migrate away, I sympathise with your dilemma over
where to go. I think CGI::Alternatives is a good document in that
respect. See also http://shadow.cat/blog/matt-s-trout/mstpan-1/

I'd probably choose Dancer2 for new work now myself, but if you want 20
year support you might prefer looking towards Catalyst, or perhaps even
building something for yourself on top of Plack.

--
Paul Johnson - paul@pjcj.net
http://www.pjcj.net
Re: Alternatives to CGI perl module [ In reply to ]
> On 10 Sep 2016, at 15:41, Paul Johnson <paul@pjcj.net> wrote:
>
> I'd probably choose Dancer2 for new work now myself, but if you want 20
> year support you might prefer looking towards Catalyst, or perhaps even
> building something for yourself on top of Plack.
>
+1 for Dancer2

And proxy to it with nginx to do ssl and serve static content

—
Clive
Re: Alternatives to CGI perl module [ In reply to ]
Can you use Dancer2 for multiple websites?

Can it handle, say, 170 object requests per second? (which is what my main
webserver does at the peak times)?

I looked at those templates .tt. I see how they have attempts at
conditional HTML generation based on application logic.

They reminded me about my attempt 16 years ago to use "Embperl" for
algebra.com.

Embperl was an attempt to make HTML websites with perl by "embedding perl"
inside HTML.

The result was disastrous and I completely removed and rewrote all emberl
code to use mod_perl and CGI module.

It turns out that HTML has a very minor and subordinate role to perl
application logic, and putting "perl inside html" was completely misguided
and instead I decided to "make html inside perl". Using CGI module of
course. This was far more maintainable.

Templating was indeed necessary, but I did it by using separate perl
modules for "presentation layer", on websites where it mattered.

Overall, I am delighted that there is a great and dedicated maintainer for
the CGI module, this gave me a lot of relief.

On Sat, Sep 10, 2016 at 1:03 PM, Clive Eisen <clive@hildebrand.co.uk> wrote:

>
> > On 10 Sep 2016, at 15:41, Paul Johnson <paul@pjcj.net> wrote:
> >
> > I'd probably choose Dancer2 for new work now myself, but if you want 20
> > year support you might prefer looking towards Catalyst, or perhaps even
> > building something for yourself on top of Plack.
> >
> +1 for Dancer2
>
> And proxy to it with nginx to do ssl and serve static content
>
> —
> Clive
>
>
Re: Alternatives to CGI perl module [ In reply to ]
On 09/10/2016 09:53 PM, Igor Chudov wrote:
> It turns out that HTML has a very minor and subordinate role to perl
> application logic, and putting "perl inside html" was completely misguided
> and instead I decided to "make html inside perl". Using CGI module of
> course. This was far more maintainable.


Just for the record, this is not correct and I think time has proven
that integrating language into the html output has resulted in a Marjory
of active server pages. Aside from Perl, there has been similar
constructions in python, rails, php, etc etc etc...

I just have a distaste for opinions spouted as facts.

If anything, CGI.PM is the clumsy huge animal and is problematic, even
from the beginning. There has always been work arounds to sidestep it
including fastcgi et al. Use of it is a (huge at times) convenience for
some, but speed, organization and efficiency are not it's benefits.



--
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 and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Re: Alternatives to CGI perl module [ In reply to ]
On Sat, Sep 10, 2016 at 6:18 AM, Igor Chudov <ichudov@gmail.com> wrote:

> I can, and will of course, install CGI myself as all my sites use it and I
> have 84,000 lines written using it.
> My concern is that it will break at some point going forward if it is not
> maintained.
>

Out of curiosity, why do you think that it's not maintained ?
It's just excluded from perl distribution and it's ok as it doesn't support
modern stuff like HTML 5, AJAX, HTTP/2, etc.


> I try to use CGI.pm in ways that are not questionable, such as using it in
> object oriented manner without importing its functions into my main
> namespace.
>
> Going forward, I think, I should get the message and switch to something
> new that will be maintained -- but to what?
>

If you don't plan to re-design your websites I'd recommend keep CGI.pm.
It's maintained, just not part of perl itself now ( DBI.pm isn't as well
and what?).
Just consider CGI as one of CPAN modules (as well as alternatives you can
find).

--
Regards,
Misha
Re: Alternatives to CGI perl module [ In reply to ]
On our Ubuntu 16.04.1 LTS, after installing mod_perl (simply out-of-the-box
with apt-get), CGI.pm installs:

/usr/lib/x86_64-linux-gnu/perl5/5.22/FCGI.pm

/usr/share/perl5/CGI.pm



We have 20+ Ubuntu LTS instances running on Google Cloud Platform, 12.04,
14.04 and 16.04, on all mod_perl and CGI.pm run fine.



Only non-issue – and only on stopping/restarting service apache2 – are
lines like these in the apache2 error.log:

[Sun Sep 11 08:31:00.430150 2016] [mpm_prefork:notice] [pid 15239] AH00169:
caught SIGTERM, shutting down

[ error] oh jeez, server dumped core

[ error] oh crap, server dumped core



Regards, Eric





On Sun, Sep 11, 2016 at 8:23 AM, Michael Bochkaryov <misha@rattler.kiev.ua>
wrote:

>
> On Sat, Sep 10, 2016 at 6:18 AM, Igor Chudov <ichudov@gmail.com> wrote:
>
>> I can, and will of course, install CGI myself as all my sites use it and
>> I have 84,000 lines written using it.
>> My concern is that it will break at some point going forward if it is not
>> maintained.
>>
>
> Out of curiosity, why do you think that it's not maintained ?
> It's just excluded from perl distribution and it's ok as it doesn't
> support modern stuff like HTML 5, AJAX, HTTP/2, etc.
>
>
>> I try to use CGI.pm in ways that are not questionable, such as using it
>> in object oriented manner without importing its functions into my main
>> namespace.
>>
>> Going forward, I think, I should get the message and switch to something
>> new that will be maintained -- but to what?
>>
>
> If you don't plan to re-design your websites I'd recommend keep CGI.pm.
> It's maintained, just not part of perl itself now ( DBI.pm isn't as well
> and what?).
> Just consider CGI as one of CPAN modules (as well as alternatives you can
> find).
>
> --
> Regards,
> Misha
>
>
>
Re: Alternatives to CGI perl module [ In reply to ]
On 09/11/2016 02:35 AM, Eric Aarts wrote:
> Only non-issue – and only on stopping/restarting service apache2 – are
> lines like these in the apache2 error.log:
>
> [Sun Sep 11 08:31:00.430150 2016] [mpm_prefork:notice] [pid 15239] AH00169:
> caught SIGTERM, shutting down
>
> [ error] oh jeez, server dumped core
>
> [ error] oh crap, server dumped core
>
>
>
> Regards, Eric

that is not a problem?


--
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 and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Re: Alternatives to CGI perl module [ In reply to ]
not for our application

I remember some 2 or 3 years ago I posted a topic for this on the forum,
but it was not answered

On Sun, Sep 11, 2016 at 8:45 AM, Ruben Safir <ruben@mrbrklyn.com> wrote:

> On 09/11/2016 02:35 AM, Eric Aarts wrote:
> > Only non-issue – and only on stopping/restarting service apache2 – are
> > lines like these in the apache2 error.log:
> >
> > [Sun Sep 11 08:31:00.430150 2016] [mpm_prefork:notice] [pid 15239]
> AH00169:
> > caught SIGTERM, shutting down
> >
> > [ error] oh jeez, server dumped core
> >
> > [ error] oh crap, server dumped core
> >
> >
> >
> > Regards, Eric
>
> that is not a problem?
>
>
> --
> 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 and extermination camps,
> but incompatible with living as a free human being. -RI Safir 2013
>
Re: Alternatives to CGI perl module [ In reply to ]
Re: Alternatives to CGI perl module Hi, Igor.

You may try http://mojolicious.org/

&#1042;&#1099; &#1087;&#1080;&#1089;&#1072;&#1083;&#1080; 10 &#1089;&#1077;&#1085;&#1090;&#1103;&#1073;&#1088;&#1103; 2016 &#1075;., 15:54:44:


I hope that this message would not be considered off topic.

I have been developing web apps since 1996 and have about 84,000 lines of perl code implementing various websites that I own. I do not work for anybody, own all websites that I work on, and these sites feed my family.

The largest website is http://www.algebra.com"]www.algebra.com and I have plenty of other websites, some to be used inside my own company, and some niche websites like http://liberatedmanuals.com"]liberatedmanuals.com. All these sites work, and all use the CGI perl module.

I always considered the CGI perl module to be a work of a genius. How it does forms, prefilling of form values, working with arguments, headers, cookies, html generation and so on were outstanding. The criticism of CGI as far as importing HTML generating functions in the main namespace is valid, but can be answered in a simple way, do not use the functionality if you do not like it (which is what I do), and use templates in your own code when necessary (as I do).

OK, so now, as of ubuntu 16.04, CGI is considered obsolete and is being phased out. I cannot change it. I am literally freaking out for two reasons, one is that I have 84,000 lines of code using it, and another is that I have hard times finding a suitable alternative.

One concern is that I want any alternatives to be maintained for the next 20 years. I can start using something new now if I can find a suitable system. I read CGI::Alternatives and I am left with a feeling that none of these will survive for 20 years. Second, while templating is important for any big consumer facing websites, it is not necessary for intranet and niche websites and makes things difficult to maintain. Additionally, templating involves more than just HTML templates and sometimes needs to be done in perl scripts, using perl functions to generate HTML as part of templating, not just HTML files.

So, I am looking for some web app framework that is sensible, has good support going forward and lets people use it "the easy way" (without a bazillion of files supporting a simple script) or the "hard way" (with templates etc). I want a module where HTML can be expressed as a perl statement.

Are these any realistically good modules made for people such as myself?

thanks



--
&#1057; &#1091;&#1074;&#1072;&#1078;&#1077;&#1085;&#1080;&#1077;&#1084;,
Eugen
mailto:kes-kes@yandex.ru
Re: Alternatives to CGI perl module [ In reply to ]
-----Original Message-----
From: Ruben Safir
Sent: Saturday, September 10, 2016 11:58 PM

>Just for the record, this is not correct and I think time has proven
>that integrating language into the html output has resulted in a Marjory
>of active server pages. [snip]

>I just have a distaste for opinions spouted as facts.

Just curious - Is that itself a fact or opinion?
Couldn’t tell.

Regards,
Joe N
Re: Alternatives to CGI perl module [ In reply to ]
Ruben, thank you for your opinion. You have your own opinion and I have
mine, and that is what makes the Internet beautiful.

Take a look at your own website coinhangout.com. It is down right now. But
take a look at its google cache:

http://webcache.googleusercontent.com/search?q=cache%3Awww.coinhangout.com&oq=cache%3Awww.coinhangout.com&aqs=chrome..69i57j69i58.1525j0j4&sourceid=chrome&ie=UTF-8

click on View Source of that.

There you see that most of the page is perl code, in embperl wrappers. Just
a little HTML head and ending is HTML.

This is what I found to be typical of most pages.



On Sat, Sep 10, 2016 at 10:58 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:

> On 09/10/2016 09:53 PM, Igor Chudov wrote:
> > It turns out that HTML has a very minor and subordinate role to perl
> > application logic, and putting "perl inside html" was completely
> misguided
> > and instead I decided to "make html inside perl". Using CGI module of
> > course. This was far more maintainable.
>
>
> Just for the record, this is not correct and I think time has proven
> that integrating language into the html output has resulted in a Marjory
> of active server pages. Aside from Perl, there has been similar
> constructions in python, rails, php, etc etc etc...
>
> I just have a distaste for opinions spouted as facts.
>
> If anything, CGI.PM is the clumsy huge animal and is problematic, even
> from the beginning. There has always been work arounds to sidestep it
> including fastcgi et al. Use of it is a (huge at times) convenience for
> some, but speed, organization and efficiency are not it's benefits.
>
>
>
> --
> 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 and extermination camps,
> but incompatible with living as a free human being. -RI Safir 2013
>
Re: Alternatives to CGI perl module [ In reply to ]
On Sun, Sep 11, 2016 at 09:46:52AM -0500, Igor Chudov wrote:
> Ruben, thank you for your opinion. You have your own opinion and I have
> mine, and that is what makes the Internet beautiful.
>
> Take a look at your own website coinhangout.com. It is down right now. But
> take a look at its google cache:


It is intentionally down, and it is not mine any longer. I don't use google but thanks

Embedded coding is the vast marjority of websights. Sorry you don't
believe it.


>
> http://webcache.googleusercontent.com/search?q=cache%3Awww.coinhangout.com&oq=cache%3Awww.coinhangout.com&aqs=chrome..69i57j69i58.1525j0j4&sourceid=chrome&ie=UTF-8
>
> click on View Source of that.
>
> There you see that most of the page is perl code, in embperl wrappers. Just
> a little HTML head and ending is HTML.
>
> This is what I found to be typical of most pages.
>
>
>
> On Sat, Sep 10, 2016 at 10:58 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:
>
> > On 09/10/2016 09:53 PM, Igor Chudov wrote:
> > > It turns out that HTML has a very minor and subordinate role to perl
> > > application logic, and putting "perl inside html" was completely
> > misguided
> > > and instead I decided to "make html inside perl". Using CGI module of
> > > course. This was far more maintainable.
> >
> >
> > Just for the record, this is not correct and I think time has proven
> > that integrating language into the html output has resulted in a Marjory
> > of active server pages. Aside from Perl, there has been similar
> > constructions in python, rails, php, etc etc etc...
> >
> > I just have a distaste for opinions spouted as facts.
> >
> > If anything, CGI.PM is the clumsy huge animal and is problematic, even
> > from the beginning. There has always been work arounds to sidestep it
> > including fastcgi et al. Use of it is a (huge at times) convenience for
> > some, but speed, organization and efficiency are not it's benefits.
> >
> >
> >
> > --
> > 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 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 and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Re: Alternatives to CGI perl module [ In reply to ]
Eugene, sorry for my ignorant questions.

I see several of these frameworks.

Is that correct that the result of setting up and programming the framework
is a running perl script?

It needs a reverse proxy in front of it? (I use nginx as a reverse proxy).

Does nginx proxy to those?

Do you need separate instances of those frameworks for every virtual host?

Can they run multithreaded? I need to run multithreaded as I need to
utilize multiple CPUs.

Is that true that the frameworks serve the entire website and, for example,
I cannot have static files like JPEGs?

Do I have to handle all URL rewriting?

On Sun, Sep 11, 2016 at 6:08 AM, Eugen Konkov <kes-kes@yandex.ru> wrote:

> Hi, Igor.
>
> You may try http://mojolicious.org/
>
> Вы писали 10 сентября 2016 г., 15:54:44:
>
>
> I hope that this message would not be considered off topic.
>
> I have been developing web apps since 1996 and have about 84,000 lines of
> perl code implementing various websites that I own. I do not work for
> anybody, own all websites that I work on, and these sites feed my family.
>
> The largest website is www.algebra.com and I have plenty of other
> websites, some to be used inside my own company, and some niche websites
> like liberatedmanuals.com. All these sites work, and all use the CGI perl
> module.
>
> I always considered the CGI perl module to be a work of a genius. How it
> does forms, prefilling of form values, working with arguments, headers,
> cookies, html generation and so on were outstanding. The criticism of CGI
> as far as importing HTML generating functions in the main namespace is
> valid, but can be answered in a simple way, do not use the functionality if
> you do not like it (which is what I do), and use templates in your own code
> when necessary (as I do).
>
> OK, so now, as of ubuntu 16.04, CGI is considered obsolete and is being
> phased out. I cannot change it. I am literally freaking out for two
> reasons, one is that I have 84,000 lines of code using it, and another is
> that I have hard times finding a suitable alternative.
>
> One concern is that I want any alternatives to be maintained for the next
> 20 years. I can start using something new now if I can find a suitable
> system. I read CGI::Alternatives and I am left with a feeling that none of
> these will survive for 20 years. Second, while templating is important for
> any big consumer facing websites, it is not necessary for intranet and
> niche websites and makes things difficult to maintain. Additionally,
> templating involves more than just HTML templates and sometimes needs to be
> done in perl scripts, using perl functions to generate HTML as part of
> templating, not just HTML files.
>
> So, I am looking for some web app framework that is sensible, has good
> support going forward and lets people use it "the easy way" (without a
> bazillion of files supporting a simple script) or the "hard way" (with
> templates etc). I want a module where HTML can be expressed as a perl
> statement.
>
> Are these any realistically good modules made for people such as myself?
>
> thanks
>
>
>
>
>
> *-- С уважением, Eugen *mailto:kes-kes@yandex.ru
> <kes-kes@yandex.ru>
>
Re: Alternatives to CGI perl module [ In reply to ]
I ca only speak for Dancer2 - I imagine they are all similar
> On 11 Sep 2016, at 15:55, Igor Chudov <ichudov@gmail.com> wrote:
>
> Eugene, sorry for my ignorant questions.
>
> I see several of these frameworks.
>
> Is that correct that the result of setting up and programming the framework is a running perl script?
>
Yes - usually a psgi so you run it under something like starman

> It needs a reverse proxy in front of it? (I use nginx as a reverse proxy).
>
IMHO this is the best way - you can use the proxy to handle the ssl if required

> Does nginx proxy to those?
>
It does so very well

> Do you need separate instances of those frameworks for every virtual host?
>
Whilst you could do it ‘all in one’ I prefer to run a separate instance per vhost

> Can they run multithreaded? I need to run multithreaded as I need to utilize multiple CPUs.
>
Starman will run as many workers as you request so - yes

> Is that true that the frameworks serve the entire website and, for example, I cannot have static files like JPEGs?
>
No Dancer2 serves static content very well, although I tend to server it directly out of nginx as it’s faster and does not require the proxy call

> Do I have to handle all URL rewriting?
>
You can do that very well in nginx

HTH

—
Clive

> On Sun, Sep 11, 2016 at 6:08 AM, Eugen Konkov <kes-kes@yandex.ru <mailto:kes-kes@yandex.ru>> wrote:
> Hi, Igor.
>
> You may try http://mojolicious.org/ <http://mojolicious.org/>
>
> Вы писали 10 сентября 2016 г., 15:54:44:
>
>
> I hope that this message would not be considered off topic.
>
> I have been developing web apps since 1996 and have about 84,000 lines of perl code implementing various websites that I own. I do not work for anybody, own all websites that I work on, and these sites feed my family.
>
> The largest website is www.algebra.com <http://www.algebra.com/> and I have plenty of other websites, some to be used inside my own company, and some niche websites like liberatedmanuals.com <http://liberatedmanuals.com/>. All these sites work, and all use the CGI perl module.
>
> I always considered the CGI perl module to be a work of a genius. How it does forms, prefilling of form values, working with arguments, headers, cookies, html generation and so on were outstanding. The criticism of CGI as far as importing HTML generating functions in the main namespace is valid, but can be answered in a simple way, do not use the functionality if you do not like it (which is what I do), and use templates in your own code when necessary (as I do).
>
> OK, so now, as of ubuntu 16.04, CGI is considered obsolete and is being phased out. I cannot change it. I am literally freaking out for two reasons, one is that I have 84,000 lines of code using it, and another is that I have hard times finding a suitable alternative.
>
> One concern is that I want any alternatives to be maintained for the next 20 years. I can start using something new now if I can find a suitable system. I read CGI::Alternatives and I am left with a feeling that none of these will survive for 20 years. Second, while templating is important for any big consumer facing websites, it is not necessary for intranet and niche websites and makes things difficult to maintain. Additionally, templating involves more than just HTML templates and sometimes needs to be done in perl scripts, using perl functions to generate HTML as part of templating, not just HTML files.
>
> So, I am looking for some web app framework that is sensible, has good support going forward and lets people use it "the easy way" (without a bazillion of files supporting a simple script) or the "hard way" (with templates etc). I want a module where HTML can be expressed as a perl statement.
>
> Are these any realistically good modules made for people such as myself?
>
> thanks
>
>
>
>
> --
> С уважением,
> Eugen mailto:kes-kes@yandex.ru <mailto:kes-kes@yandex.ru>
Re: Alternatives to CGI perl module [ In reply to ]
On Sun, Sep 11, 2016 at 09:46:52AM -0500, Igor Chudov wrote:
> Ruben, thank you for your opinion. You have your own opinion and I have
> mine, and that is what makes the Internet beautiful.
>
> Take a look at your own website coinhangout.com. It is down right now. But
> take a look at its google cache:
>
> http://webcache.googleusercontent.com/search?q=cache%3Awww.coinhangout.com&oq=cache%3Awww.coinhangout.com&aqs=chrome..69i57j69i58.1525j0j4&sourceid=chrome&ie=UTF-8
>
> click on View Source of that.
>
> There you see that most of the page is perl code, in embperl wrappers. Just
> a little HTML head and ending is HTML.
>
> This is what I found to be typical of most pages.


That is called templates, BTW and is common. In that case I was
importing a large modperl application and embedding it into a second
page. It was pretty quick and dirty but it did the job to about 80K
hits a day on a little atom fit/pc processor.

I stopped using the page when someone stole all the coins on the site
from their home. I lost my stomach for it and passed the site along to a
friend who may or may not be using it.

That doesn't make CGI.pm any less of a pig. It is th swiss army knife
of internet programming, but it has a huge cost, especailly if you are
using large pages heavy on content that are cached in RAM. It also runs
a lot of contacts, and can gum up the OS scheduler and wait cues real good.




>
>
>
> On Sat, Sep 10, 2016 at 10:58 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:
>
> > On 09/10/2016 09:53 PM, Igor Chudov wrote:
> > > It turns out that HTML has a very minor and subordinate role to perl
> > > application logic, and putting "perl inside html" was completely
> > misguided
> > > and instead I decided to "make html inside perl". Using CGI module of
> > > course. This was far more maintainable.
> >
> >
> > Just for the record, this is not correct and I think time has proven
> > that integrating language into the html output has resulted in a Marjory
> > of active server pages. Aside from Perl, there has been similar
> > constructions in python, rails, php, etc etc etc...
> >
> > I just have a distaste for opinions spouted as facts.
> >
> > If anything, CGI.PM is the clumsy huge animal and is problematic, even
> > from the beginning. There has always been work arounds to sidestep it
> > including fastcgi et al. Use of it is a (huge at times) convenience for
> > some, but speed, organization and efficiency are not it's benefits.
> >
> >
> >
> > --
> > 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 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 and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Re: Alternatives to CGI perl module [ In reply to ]
On Sun, Sep 11, 2016 at 10:23 AM, Ruben Safir <ruben@mrbrklyn.com> wrote:

> On Sun, Sep 11, 2016 at 09:46:52AM -0500, Igor Chudov wrote:
> > Ruben, thank you for your opinion. You have your own opinion and I have
> > mine, and that is what makes the Internet beautiful.
> >
> > Take a look at your own website coinhangout.com. It is down right now.
> But
> > take a look at its google cache:
> >
> > http://webcache.googleusercontent.com/search?
> q=cache%3Awww.coinhangout.com&oq=cache%3Awww.coinhangout.
> com&aqs=chrome..69i57j69i58.1525j0j4&sourceid=chrome&ie=UTF-8
> >
> > click on View Source of that.
> >
> > There you see that most of the page is perl code, in embperl wrappers.
> Just
> > a little HTML head and ending is HTML.
> >
> > This is what I found to be typical of most pages.
>
>
> That is called templates, BTW and is common. In that case I was
> importing a large modperl application and embedding it into a second
> page. It was pretty quick and dirty but it did the job to about 80K
> hits a day on a little atom fit/pc processor.
>
> I stopped using the page when someone stole all the coins on the site
> from their home. I lost my stomach for it and passed the site along to a
> friend who may or may not be using it.
>
>
I am sorry to hear this, I am sure that it was a sad moment. Remind your
friend to change the WHOIS information on this domain.


> That doesn't make CGI.pm any less of a pig. It is th swiss army knife
> of internet programming, but it has a huge cost, especailly if you are
> using large pages heavy on content that are cached in RAM. It also runs
> a lot of contacts, and can gum up the OS scheduler and wait cues real good.
>
>
>
I use CGI.pm exclusively inside mod_perl. At peak demand around 7pm on week
days, when everyone is doing homework, I serve about 170 or so requests per
second. The server is a 8 CPU virtual server running in google cloud and it
is about 50% busy.

About maybe half of those responses are images generated by mod_perl/CGI.pm
scripts that draw pictures of math formulas like x/(x+1) etc.

I agree that running CGI.pm inside true CGI scripts (one process per every
web object) is expensive. Running it inside mod_perl seems to be extremely
efficient.


>
> >
> >
> >
> > On Sat, Sep 10, 2016 at 10:58 PM, Ruben Safir <ruben@mrbrklyn.com>
> wrote:
> >
> > > On 09/10/2016 09:53 PM, Igor Chudov wrote:
> > > > It turns out that HTML has a very minor and subordinate role to perl
> > > > application logic, and putting "perl inside html" was completely
> > > misguided
> > > > and instead I decided to "make html inside perl". Using CGI module of
> > > > course. This was far more maintainable.
> > >
> > >
> > > Just for the record, this is not correct and I think time has proven
> > > that integrating language into the html output has resulted in a
> Marjory
> > > of active server pages. Aside from Perl, there has been similar
> > > constructions in python, rails, php, etc etc etc...
> > >
> > > I just have a distaste for opinions spouted as facts.
> > >
> > > If anything, CGI.PM is the clumsy huge animal and is problematic, even
> > > from the beginning. There has always been work arounds to sidestep it
> > > including fastcgi et al. Use of it is a (huge at times) convenience
> for
> > > some, but speed, organization and efficiency are not it's benefits.
> > >
> > >
> > >
> > > --
> > > 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 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 and extermination camps,
> but incompatible with living as a free human being. -RI Safir 2013
>
>
Re: Alternatives to CGI perl module [ In reply to ]
On 09/11/2016 11:38 AM, Igor Chudov wrote:
> About maybe half of those responses are images generated by mod_perl/CGI.pm
> scripts that draw pictures of math formulas like x/(x+1) etc.
>
> I agree that running CGI.pm inside true CGI scripts (one process per every
> web object) is expensive. Running it inside mod_perl seems to be extremely
> efficient.


interesting. How big are those graphics. We had to pull modperl from
service at about.com because of the ram foot print and the contact
limitations, even with semiphores pulled way up. If your producing
images like gnuplot, then your approach has many advantages, not the
least of which is flexibility. If your doing something like my images
gallery, it would be less efficient, although I still run it under
modperl in the hopes that I'm caching a good percentage of my images in
the apache server.

Regardless, the point that you made that I felt was condensing and
inaccurate was the efficiency of CGI.pm was superior, and that embedded
coding was inefficient and disorganized. I can go straight to the
Lincoln Stein book and quote his opinions on CGI.pm's bloat. No matter
what you are using, your making some templates and reoccurring HTML. Or
maybe not, maybe each of your pages are unique, completely.

OK with that o/o.

Ruben
--
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 and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Re: Alternatives to CGI perl module [ In reply to ]
CGI.pm is still good - but i you are using modperl "properly" then it is
worth look at APR, which when you use CGI.pm under mod_perl it is what
is used under the hood... and is faster than CGI (one less level of
abstraction) although there is a minor bug in it - in that is broken if
you use modperl when it doesn't expand the environment.

We moved away from CGI to using APR as this made life in our mod_perl
framework.

Yes you can look at PSGI and Plack - but in our situation we found quite
a number of issues causing DOS attacks in this setup - some of our
requests are very heavy and we wanted to selectively choose multiple
layers (as in different combinations of handlers) to the application -
both things PSGI/Plack's design doesn't like. Also we have 100s of
applications running on the same server which doesn't work nicely in the
plack environment - multiple servers would really be required which adds
to server over head...

As for templates - invariably if you want to apply sitewide style to a
site they are the WRONG solution - but I've had this debate with many
people and most don't see the point - until I point out how simple I can
change the way tables work on a site... It does involve writing good
CSS/JS and not relying on the presentational frameworks which are get
far to common place!


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



--
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: Alternatives to CGI perl module [ In reply to ]
On Sun, Sep 11, 2016 at 11:08 AM, Ruben Safir <ruben@mrbrklyn.com> wrote:

> On 09/11/2016 11:38 AM, Igor Chudov wrote:
> > About maybe half of those responses are images generated by
> mod_perl/CGI.pm
> > scripts that draw pictures of math formulas like x/(x+1) etc.
> >
> > I agree that running CGI.pm inside true CGI scripts (one process per
> every
> > web object) is expensive. Running it inside mod_perl seems to be
> extremely
> > efficient.
>
>
> interesting. How big are those graphics.


Examples of graphics are here:

https://www.algebra.com/services/rendering/

I draw these pictures on the fly using GD::Graph, by parsing formulas and
rendering them in proper notation.


> We had to pull modperl from
> service at about.com because of the ram foot print and the contact
> limitations, even with semiphores pulled way up.


About.com has about 19M monthly visitors, according to quantcast.
Algebra.com about 2.4 million, about 8 times less.

I had similar problems of all kinds when my traffic grew, including, as I
clearly recall, RAM and semaphores, and also a lot of sql performance
problems.

The semaphores I had to clean up often from cron using a script that I
found online. I also specify restart of apache children after so many
requests etc. Had to do a lot of sql optimization.

The result it that everything functions smoothly.

My analogue is that there are typical pets like a dog, a cat or a parrot.
But a pet elephant is a special pet, you need a truck just to bring food
and the flor would cave in so you need to do a lot more if you have a pet
elephant.

Same with having any large site, there is work that a small site does not
have to do.

If your producing
> images like gnuplot, then your approach has many advantages, not the
> least of which is flexibility. If your doing something like my images
> gallery, it would be less efficient, although I still run it under
> modperl in the hopes that I'm caching a good percentage of my images in
> the apache server.
>
>
I chose not to cache any images and I render every single image on the fly.
This actually scales better than caching them.


> Regardless, the point that you made that I felt was condensing and
> inaccurate was the efficiency of CGI.pm was superior, and that embedded
> coding was inefficient and disorganized. I can go straight to the
> Lincoln Stein book and quote his opinions on CGI.pm's bloat. No matter
> what you are using, your making some templates and reoccurring HTML. Or
> maybe not, maybe each of your pages are unique, completely.
>
> OK with that o/o.
>
>
Ruben, I understand that, for example, PHP is an embedded language. But if
you look at almost any big php project, such as mediawiki or whatever, most
of them immediately revert to "make HTML inside PHP code" as opposed to
"embed PHP code in HTML". Look at mediawiki php source files. This is how
these projects evolve.



> Ruben
> --
> 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 and extermination camps,
> but incompatible with living as a free human being. -RI Safir 2013
>
Re: Alternatives to CGI perl module [ In reply to ]
On 09/11/2016 05:36 PM, Igor Chudov wrote:
> Examples of graphics are here:
>
> https://www.algebra.com/services/rendering/
>
> I draw these pictures on the fly using GD::Graph, by parsing formulas and
> rendering them in proper notation.


GD Graph might be a longer term problem than CGI.pm

--
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 and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Re: Alternatives to CGI perl module [ In reply to ]
you are right.

It does not even compile correctly any more due to some stupid and
incorrect logic in Makefile.PL related to major and minor perl versions. I
have to edit Makefile.PL prior to compiling it.

It has no real future, sadly.

GD::Graph is something that is not going to kill me (like if CGI.pm became
unavailable) but it is certainly a concern.

Are there any alternatives to it?


On Sun, Sep 11, 2016 at 5:50 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:

> On 09/11/2016 05:36 PM, Igor Chudov wrote:
> > Examples of graphics are here:
> >
> > https://www.algebra.com/services/rendering/
> >
> > I draw these pictures on the fly using GD::Graph, by parsing formulas and
> > rendering them in proper notation.
>
>
> GD Graph might be a longer term problem than CGI.pm
>
> --
> 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 and extermination camps,
> but incompatible with living as a free human being. -RI Safir 2013
>
Re: Alternatives to CGI perl module [ In reply to ]
On 09/11/2016 07:43 PM, Igor Chudov wrote:
> you are right.
>
> It does not even compile correctly any more due to some stupid and
> incorrect logic in Makefile.PL related to major and minor perl versions. I
> have to edit Makefile.PL prior to compiling it.
>
> It has no real future, sadly.
>
> GD::Graph is something that is not going to kill me (like if CGI.pm became
> unavailable) but it is certainly a concern.
>
> Are there any alternatives to it?
>
imagemajic maybe

>
> On Sun, Sep 11, 2016 at 5:50 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:
>
>> On 09/11/2016 05:36 PM, Igor Chudov wrote:
>>> Examples of graphics are here:
>>>
>>> https://www.algebra.com/services/rendering/
>>>
>>> I draw these pictures on the fly using GD::Graph, by parsing formulas and
>>> rendering them in proper notation.
>>
>>
>> GD Graph might be a longer term problem than CGI.pm
>>
>> --
>> 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 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 and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

1 2  View All