Re: [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script

[Jakub Narebski <jnareb@gmail.com>]

On Fri, 14 May 2010, Peter Vereshagin wrote:
> 2010/05/14 12:53:42 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :

>> legitimate uses of 'goto' that make the program simpler to understand,
>> and not harder,... among those is handling exceptions.
> 
> so did you change the exception-related exit()s on your patch to the
> "last" ?

Yes, die_error(), which had "exit" that got replaced by non-local "goto"
is exception-related subroutine.


>> The problem is that "do <file>;" is similar to "eval `cat <file>`;"
>> (except that it's more efficient and concise), it that it silences
>> parsing errors.  From `perldoc -f do`:
>> 
>>   If "do" cannot read the file, it returns undef and sets $! to the error.
>>   If "do" can read the file but cannot compile it, it returns undef and sets
>>   an error message in $@.   If the file is successfully compiled, "do"
>>   returns the value of the last expression evaluated.
>> 
>>> And yes, since it's about development but not production use, die is just fine
>>> in the inclusion code like this:
>>> 
>>> eval( 'use Module;' ); die $@ if $@;
>> 
>> Wrong!
> 
> The problem was you can't see the reason of the inclusion-via-do()
> parsing failure.

You don't see the parsing failure because "do <file>;" functions like
"eval", which traps exceptions.  You will see consequences of parsing
failure (like not defined subroutine).

> But you may see it with "use warnings;" right?

"use warnings;" pragma doesn't help, because of the 'trapping
exceptions' part.  That is why "require <file>" is recommended over 
"do <file>".

>>> as always, require() can do the trick, not to mention usual 
>>> 
>>> use Module;
>>> 
>>> This all will cause die() when it's necessary as only the application developer
>>> knows how strict is the dependence on the Module. In some cases, application
>>> can work without some Module but it's just better with it.
>> 
>> First, both "use Module;" and "require Module;" (and "require '<file>';")
>> do automatic error checking and raise an exception if there is problem.
> 
> for web applications, half of exceptions or more are generated when the user
> isn't the develioper.
> Notifications() via the logs are just enough and more than it: should be the
> prefered way of exceptions' notifications in a production.
> Why worry about return code then?

Checking $@ after "do <file>" would cover the situation where there were
parsing errors, but wouldn't cover situation where file was not found,
or there was error in executing code (but parsing was O.K.).
 
>> Second, "use Module <LIST>;" is equivalent to
>>   BEGIN { require Module; import Module <LIST>; }
>> and therefore it doesn't make sense to use it for conditional inclusion.
> 
> eval() is used there.

It's the fact that "use Module" uses BEGIN block that is incompatibile
with *conditional* using it from eval.

>>>> PSGI is interface, Plack is reference implementation.  You can run PSGI
>>>> app on any supported web server; this includes running PSGI apps on
>>>> FastCGI.
>>> 
>>> Existing problem FCGI::Spawn for is not the PSGI applications to be run as a
>>> FastCGI, but the bunch of existing CGI.pm applications (even gitorious) need
>>> to be more effective with the widest-spread protocol FastCGI. Best without any
>>> patching of the application, deployed the same simple way as with apache's cgi
>>> implementation.
>> 
>> Gitorious is in Ruby, therefore is not a CGI.pm application, as it is
>> not even in Perl.
> 
> It was Girocco you mentioned earlier

Girocco is shell scripts, not Perl either, see
http://repo.or.cz/w/girocco.git/tree

>> By using Plack::App::CGIBin you can load CGI scripts from a directory
>> and convert them into a <persistent> PSGI application.  You can use
> 
> Such a conversion is more than a compilation? Does it mean converted CGI app
> should be stored before to become a persistent application?

This convertion is 
a.) compiling CGI file into subroutine (taking care of things like DATA
    filehandle) using CGI::Compile
b.) converting between CGI interface and PSGI interface, using
    CGI::Emulate::PSGI


CGI::Compile manpage includes this example:

         use CGI::Emulate::PSGI;
         use CGI::Compile;

         my $cgi_script = "/path/to/foo.cgi";
         my $sub = CGI::Compile->compile($cgi_script);
         my $app = CGI::Emulate::PSGI->handler($sub);

         # $app is a PSGI application

>> Plack::App::WrapCGI to convert single CGI script into PSGI application.
>> You can use Plack::Buuilder's domain specific language to join (map)
>> together a bunch of PSGI applications (in different paths) in a single
>> app (via Plack::App::URLMap).
> 
> And can the same process of that application server run for the several
> applications depending on the FastCGI request?

Yes, it can.  Depending on request it would run appropriate
CGI-converted-to-PSGI application.

I am not sure how Plack::App::CGIBin works internally; it migh cimpile
all CGI applications upfront; but it might not.
 
>> You can then run PSGI application (for example the PSGI app which loads
>> CGI apps via Plack::App::CGIBin) on any supported web server, which
>> includes FCGI (FastCGI).

-- 
Jakub Narebski
Poland