Re: Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-10-04 Thread Chris Bennett
On Tue, Oct 04, 2016 at 09:44:24AM -0700, Andrew Fresh wrote:
> On Tue, Oct 04, 2016 at 12:20:33PM -0400, Raul Miller wrote:
> > On Tue, Oct 4, 2016 at 8:48 AM, Marc Espie  wrote:
> > > There's also a whole fucking manpage bundled with PerlDancer explaining in
> > > some details all the possible deployment options.
> > 
> > Related, though, is that a lot (but not all) of this documentation
> > assumes the reader understands how to use mod_perl -- and incorporates
> > its documentation by reference, or by implication.
> 
> This is getting off-topic for misc@, but the Plack and mod_perl are
> fairly low-level so I don't think it's unfair to expect a reader who is
> converting from one to the other to be familiar with them.  Then again,
> the PSGI spec is not incredibly dense.
> 
> https://metacpan.org/pod/PSGI
> 
> And the FAQ seems to answer questions expecting, what seemed to me,
> a reasonable knowledge level.
> 
> https://metacpan.org/pod/distribution/PSGI/PSGI/FAQ.pod
> 
> 
> > People who don't understand that are probably expected to either
> > figure it out for themselves, or migrate to some other environment
> > (which might account for some of the popularity of node.js, rails and
> > python).
> 
> While the page at http://plackperl.org/ could possibly be a bit
> friendlier, it does have links to explain what it is and how it works,
> plus links to something like 18 higher-level frameworks that support
> PSGI, likely via Plack, 
> 
> 
> I think the hope is more that you might find the Task::Kensho link off
> of the metacpan.org main page and from there follow the links to some of
> the many perl web development frameworks that exist.
> 
> https://metacpan.org/pod/Task::Kensho#Task::Kensho::WebDev:-Web-Development
> 
> (I am in the middle of doing this at work, so may not have a good handle
> on how someone new sees things)
> 
> l8rZ,
> -- 
> andrew - http://afresh1.com
> 
> At the source of every error which is blamed on the computer, you
> will find at least two human errors, including the error of blaming
> it on the computer.

Yes, this may be OT for misc, feel free to move this to ports.

I very much appreciate any guidance on this. I also hope this topic
helps others who are now having to make a move away from
mod_perl/Apache2.

I also have some software to use that has FastCGI/Starman as it's ideal
installation method.

And thank you Espie for suggestion Dancer as a good manual reading.
It is.

I'm going to go ahead and send this over to ports, where it belongs.
Apache2/mod_perl are truly dead except for some die-hards.


Thanks,
Chris Bennett



Re: Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-10-04 Thread Chris Bennett
On Tue, Oct 04, 2016 at 12:20:33PM -0400, Raul Miller wrote:
> On Tue, Oct 4, 2016 at 8:48 AM, Marc Espie  wrote:
> > There's also a whole fucking manpage bundled with PerlDancer explaining in
> > some details all the possible deployment options.
> 
> Related, though, is that a lot (but not all) of this documentation
> assumes the reader understands how to use mod_perl -- and incorporates
> its documentation by reference, or by implication.
> 

There is documentation, if one wants to reach that far in calling it
useful, for the migration at perl.apache.org.
It is of deplorable and unbelievably low quality. Such documetantion would
definitely get a FU here in OpenBSD. And I sent just such a message to
modp...@perl.apache.org. I haven't looked at any replies yet.
Their list of searchable mailing list archives yields only one site that
is useful plus a long list of useless/non-existent sites.


> People who don't understand that are probably expected to either
> figure it out for themselves, or migrate to some other environment
> (which might account for some of the popularity of node.js, rails and
> python).
> 

I understand mod_perl1 reasonably well, but with ~= 50 modules in
mod_perl, I'm just not willing to suffer such a ridiculous task,
especially since mod_perl2 may be dropped by OpenBSD in the future.
So if I have to do a monumental task, better to move to something else!

Chris Bennett



Re: Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-10-04 Thread Roderick

On Thu, 29 Sep 2016, Chris Bennett wrote:


Thanks to stu@, he's informed me that mod_perl is a big problem for
OpenBSD modernising its Perl forward.
So I'm going to try and move to FastCGI.


[...]


I'm going to go study FastCGI myself now.


I think perhaps there is a much better and simpler alternative to FastCGI:
to use the proxy capability of a http server and to embed a
specialized http server (only few lines in C or a scripting language)
in your application.

It seems that FastCGI still could have an advantage, like multiplexing,
but very probably you will not need it.

See for example:

https://ef.gy/fastcgi-is-pointless

Rodrigo.



Re: Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-10-04 Thread Andrew Fresh
On Tue, Oct 04, 2016 at 12:20:33PM -0400, Raul Miller wrote:
> On Tue, Oct 4, 2016 at 8:48 AM, Marc Espie  wrote:
> > There's also a whole fucking manpage bundled with PerlDancer explaining in
> > some details all the possible deployment options.
> 
> Related, though, is that a lot (but not all) of this documentation
> assumes the reader understands how to use mod_perl -- and incorporates
> its documentation by reference, or by implication.

This is getting off-topic for misc@, but the Plack and mod_perl are
fairly low-level so I don't think it's unfair to expect a reader who is
converting from one to the other to be familiar with them.  Then again,
the PSGI spec is not incredibly dense.

https://metacpan.org/pod/PSGI

And the FAQ seems to answer questions expecting, what seemed to me,
a reasonable knowledge level.

https://metacpan.org/pod/distribution/PSGI/PSGI/FAQ.pod


> People who don't understand that are probably expected to either
> figure it out for themselves, or migrate to some other environment
> (which might account for some of the popularity of node.js, rails and
> python).

While the page at http://plackperl.org/ could possibly be a bit
friendlier, it does have links to explain what it is and how it works,
plus links to something like 18 higher-level frameworks that support
PSGI, likely via Plack, 


I think the hope is more that you might find the Task::Kensho link off
of the metacpan.org main page and from there follow the links to some of
the many perl web development frameworks that exist.

https://metacpan.org/pod/Task::Kensho#Task::Kensho::WebDev:-Web-Development

(I am in the middle of doing this at work, so may not have a good handle
on how someone new sees things)

l8rZ,
-- 
andrew - http://afresh1.com

At the source of every error which is blamed on the computer, you
will find at least two human errors, including the error of blaming
it on the computer.



Re: Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-10-04 Thread Raul Miller
On Tue, Oct 4, 2016 at 8:48 AM, Marc Espie  wrote:
> There's also a whole fucking manpage bundled with PerlDancer explaining in
> some details all the possible deployment options.

Related, though, is that a lot (but not all) of this documentation
assumes the reader understands how to use mod_perl -- and incorporates
its documentation by reference, or by implication.

People who don't understand that are probably expected to either
figure it out for themselves, or migrate to some other environment
(which might account for some of the popularity of node.js, rails and
python).

-- 
Raul



Re: Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-10-04 Thread Chris Bennett
On Tue, Oct 04, 2016 at 02:48:58PM +0200, Marc Espie wrote:
> On Thu, Sep 29, 2016 at 12:45:10PM -0700, Andrew Fresh wrote:
> > I gave a talk about moving from mod_perl to Plack and FastCGI at the local
> > perlmonger group. It was fairly straight forward and there are a fair number
> > of options on the CPAN, although I'm unsure which have ports.
> > 
> > http://cvs.afresh1.com/~andrew/talks/cgi_to_psgi_pdx_pm/
> > 
> > There is also some potentially useful information in this article
> > 
> > https://github.com/reyk/httpd/wiki/Migrating-a-perl-CGI-application-such-as-B
> > ugzilla
> 
> There's also a whole fucking manpage bundled with PerlDancer explaining in
> some details all the possible deployment options.

Thanks! Thats just what I was looking for.
Aside from my own software, I also am going to install some software
that now has FastCGI with Starman as the ideal install.

Screw Apache2. Apache1 served me well. RIP.


Chris Bennett



Re: Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-10-04 Thread Marc Espie
On Thu, Sep 29, 2016 at 12:45:10PM -0700, Andrew Fresh wrote:
> I gave a talk about moving from mod_perl to Plack and FastCGI at the local
> perlmonger group. It was fairly straight forward and there are a fair number
> of options on the CPAN, although I'm unsure which have ports.
> 
> http://cvs.afresh1.com/~andrew/talks/cgi_to_psgi_pdx_pm/
> 
> There is also some potentially useful information in this article
> 
> https://github.com/reyk/httpd/wiki/Migrating-a-perl-CGI-application-such-as-B
> ugzilla

There's also a whole fucking manpage bundled with PerlDancer explaining in
some details all the possible deployment options.



Re: Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-09-29 Thread Andrew Fresh
I gave a talk about moving from mod_perl to Plack and FastCGI at the local
perlmonger group. It was fairly straight forward and there are a fair number
of options on the CPAN, although I'm unsure which have ports.

http://cvs.afresh1.com/~andrew/talks/cgi_to_psgi_pdx_pm/

There is also some potentially useful information in this article

https://github.com/reyk/httpd/wiki/Migrating-a-perl-CGI-application-such-as-B
ugzilla

On September 29, 2016 12:19:50 PM PDT, Chris Bennett
 wrote:
>Thanks to stu@, he's informed me that mod_perl is a big problem for
>OpenBSD modernising its Perl forward.
>So I'm going to try and move to FastCGI.
>
>I can't find any info online about transition from mod_perl to FastCGI,
>so I'll have to work that out myself. Any useful links would be
>appreciated.
>
>Since I have been using Apache, I haven't paid any attention to base
>http.
>
>I have written modules to allow people to setup to make a purchase for
>online content, be transferred over to PayPal, pay.
>PayPal then sends me payment details which I have to send back to
>verify
>status of purchase. After that I create a username and password and
>email those plus a link to the customer.
>
>Privately, I have several databases that I use to form project assembly
>pieces that can then be combined in different ways to produce final,
>different complete project. Project labor is also worked out similarly.
>
>I also run two forums on outside software.
>
>I use PostgreSQL. I use Apache's httpd.conf and other confs to match
>Locations to the appropriate modules.
>
>Are there any problems getting something like this to work with base
>httpd? I run several different sites.
>The manual pages seem a little terse and unrevealing to me.
>
>I'm going to go study FastCGI myself now.
>
>Could anyone share some httpd.confs with me that do what I'm trying to
>accomplish?
>
>Any help appreciated,
>Chris Bennett

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Forget mod_perl. I'm going to try to move to FastCGI and base http

2016-09-29 Thread Chris Bennett
Thanks to stu@, he's informed me that mod_perl is a big problem for
OpenBSD modernising its Perl forward.
So I'm going to try and move to FastCGI.

I can't find any info online about transition from mod_perl to FastCGI,
so I'll have to work that out myself. Any useful links would be
appreciated.

Since I have been using Apache, I haven't paid any attention to base
http.

I have written modules to allow people to setup to make a purchase for
online content, be transferred over to PayPal, pay.
PayPal then sends me payment details which I have to send back to verify
status of purchase. After that I create a username and password and
email those plus a link to the customer.

Privately, I have several databases that I use to form project assembly
pieces that can then be combined in different ways to produce final,
different complete project. Project labor is also worked out similarly.

I also run two forums on outside software.

I use PostgreSQL. I use Apache's httpd.conf and other confs to match
Locations to the appropriate modules.

Are there any problems getting something like this to work with base
httpd? I run several different sites.
The manual pages seem a little terse and unrevealing to me.

I'm going to go study FastCGI myself now.

Could anyone share some httpd.confs with me that do what I'm trying to
accomplish?

Any help appreciated,
Chris Bennett