Any time of year you can find me here Vladimir.
2009/07/10 03:36:01 +0400 Vladimir Timofeev <vovkasm@gmail.com> => To Peter Vereshagin :
Show quoted textVT> > First, TCP sockets. FCGI::Spawn does them, the POD is fixed as of 0.14
VT> Thanks, but I still can not understand how run an external FCGI
VT> daemon, which will be listening to, say, localhost:8080
Such a thing is located inside FCGI
~/.cpan/build/FCGI-0.67/remote.fpl
===
## Sample Apache configuration on the webserver to refer to the
## remote script on "otherhost"
# <IFModule mod_fastcgi.c>
# AddHandler fastcgi-script fcgi
# FastCgiExternalServer /path-to/cgi-bin/external.fcgi -host otherhost:8888
# </IfModule>
# Access the URL:
http://webserver/cgi-bin/external.fcgi
# Contributed by Don Bindner <dbindner@truman.edu>
use FCGI;
my $socket = FCGI::OpenSocket( ":8888", 5 );
my $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR,
\%ENV, $socket );
===
perldoc FCGI
===
FCGI::OpenSocket(path, backlog)
Creates a socket suitable to use as an argument to Request.
path Pathname of socket or colon followed by local tcp port.
===
perldoc CGI::Fast
===
FCGI_SOCKET_PATH
The address (TCP/IP) or path (UNIX Domain) of the socket the exter
nal FastCGI script to which bind an listen for incoming connections
from the web server.
===
So as I mentioned you should set $ENV{FCGI_SOCKET_PATH} before the CGI::Fast's BEGIN{} block is evaluated. FCGI::PM does evaluate it too, by far.
Show quoted textVT> In that case architecture is:
VT> nginx - effectively serve static content, for dinamic content it
VT> dispatch requests to Catalyst application with FCGI protocol on
VT> another computer in network.
VT> fcgi-daemons - listens on some ports, serve requests... it's big
VT> Catalyst applications.
VT> Can you explain this? And I upgrade my docs as soon as possible :-)
Catalyst's FastCGI and SCGI engines contain their own accept() loops so they are inappropriate for FCGI::Spawn, right.
Catalyst's CGI engine doesn't take CGI or CGI::Simple object from outside so it's not appropriate for FCGI::Spawn, right.
But I care about different thing. I never claimed FCGI::Spawn can serve for Catalyst. It's different subject.
Agree about TCP?
Show quoted textVT>
VT> > Second, CGI::Fast. Is it any bad for anyone? Even FCGI::PM::MaxRequests does use it as synopsis too, doesn't it? So just is it a problem at all?
VT> I adapted SYNOPSIS from FCGI::ProcManager POD (real life example in
VT> USING WITH CATALYST section). And difference is in who requires the
VT> use of CGI:: Fast, user or the module author.
VT> As for CGI::Fast, it's not bad (and it with CGI itself in perl core).
VT> But alternatives exists because CGI::Fast extends CGI which is big
VT> overhead for frameworks, because of that Catalyst, for ex, using
VT> CGI::Simple
CGI::Fast is overhead for big applications, right. CGI.pm, as the base used for it, is bad thing for these cases, right.
Question is: isn't the Synopsis a mandatory part of the documentation? So, if CGI::Fast is a good thing, it should be present in Synopsis as a recommendation. If CGI::Fast is a bad thing, it shouldn't. How can I use the FCGI::PM::MaxRequests if there is no recommended way to do this? CGI::Fast is a drawback and shouldn't be used as it follows from Synopsis.
I don't negate it may be a bad idea to use CGI::Fast inside the FCGI::PM subclass and it is in the TODO list of FCGI::Spawn's POD as I'm about to make it suitable for SCGI. CGI.pm usage can be avoided with some CGI::Fast kind of extension, for example, if it's the only misadvantage of the CGI::Fast. I can use that same CGI::Simple as a base for CGI::Fast modification, if needed, no problem.
Problem about CGI::Fast on your side is: controversy of FCGI::PM::MaxRequests POD: the Synopsis uses CGI::Fast as a good practice, but FCGI::Spawn section describes CGI::Fast as a FCGI::Spawn's bad practice.
If it's problem of documentation, it concerns FCGI::Spawn and it is a problem of mis-spelling about comparison of the FCGI::PM::MaxRequests with the other code, so it is the problem of the FCGI::PM::MaxRequest's code or it shouldn't concern FCGI::Spawn as a documentation.
If it's a problem of code that can not have clear synopsis, well, it is a problem of code and this should be documented as the absence of the clear way to use.
You simply recommend to use FCGI::PM::MaxRequests in a way it shouldn't be used, right?
Show quoted textVT>
VT> >
VT> > Thank you.
VT> >
VT> > 73! Peter
VT> > - --
VT> >
http://vereshagin.org
VT> > -----BEGIN PGP SIGNATURE-----
VT> > Version: Vereshagin v2.0.10 (CP/M)
VT> >
VT> > iEYEARECAAYFAkpV5YsACgkQDOFKrKDiZicgOgCgqgHUktjdaSb/Jd3JkvzV+tTQ
VT> > meEAn1X8puWBYKnTC9PgfrBy1IffPxci
VT> > =24Be
VT> > -----END PGP SIGNATURE-----
VT> >
VT>
VT> --
VT> -- vovkasm
73! Peter
--
http://vereshagin.org
