From: Jakub Narebski <jnareb@gmail.com>
To: Tatsuhiko Miyagawa <miyagawa@gmail.com>
Cc: git@vger.kernel.org, Peter Vereshagin <peter@vereshagin.org>,
Petr Baudis <pasky@suse.cz>, Eric Wong <normalperson@yhbt.net>,
Sam Vilain <sam.vilain@catalyst.net.nz>,
Juan Jose Comellas <juanjo@comellas.org>,
John Goerzen <jgoerzen@complete.org>
Subject: Re: gitweb, FastCGI and PSGI/Plack
Date: Mon, 10 May 2010 23:10:47 +0200 [thread overview]
Message-ID: <201005102310.47879.jnareb@gmail.com> (raw)
In-Reply-To: <AANLkTilXqAUs5-go-JHgTrQuslTyA1sZ3re5yuLtnxkz@mail.gmail.com>
On Mon, 10 May 2010, Tatsuhiko Miyagawa wrote:
> On Mon, May 10, 2010 at 11:40 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Mon, 10 May 2010, Tatsuhiko Miyagawa wrote:
>>>
>>> Yes, that makes sense - if implementing FastCGI is just switching CGI
>>> to CGI::Fast and a while loop, implementing PSGI interface just for
>>> that is far more complicated. I just argued about it because I saw on
>>> a separate thread that PSGI implementation is also on its way.
>>
>> What!? No, currently there are no plans to add PSGI support to gitweb,
>> nor moving gitweb from CGI (and mod_perl's ModPerl::Registry, and
>> FastCGI now) to PSGI.
>>
>> This separate thread is about adding support for 'plackup' to
>> git-instaweb (and perhaps also adding gitweb.psgi wrapper).
>
> Yes, that's what I meant.
>
> If you get plackup support by converting your CGI application into a
> PSGI app, then adding support to FastCGI is just one command line
> option away.
Well, the support for 'plackup' in git-instaweb is / would be done not
by converting gitweb from CGI to PSGI app, but by using gitweb.psgi
wrapper. This wrapper uses Plack::App::WrapCGI (which in turn uses
CGI::Emulate::PSGI, which in turn use CGI::Compile) to wrap gitweb.cgi,
and Plack::Middleware::Static to serve static files (gitweb.css,
gitweb.js, git-favicon.png, git-logo.png).
To be more exact in current, as yet unpublished version, git-instaweb
generates gitweb.psgi on-the-fly. I am considering adding gitweb.psgi
wrapper to git repository (to git sources); when building git-instaweb
it would get embedded in $(gitexecdir)/git-instaweb, just like
gitweb.cgi, gitweb.css (or gitweb.min.css) and gitweb.js (or
gitweb.min.js) are. Running git-instaweb for first time would create
_configured_ gitweb.cgi in $GIT_DIR/gitweb. For "plackup" git-instaweb
would put configured gitweb.psgi (or app.psgi) there; for other web
servers git-instaweb puts httpd.conf there.
It is true that with gitweb.psgi wrapper running gitweb as FastCGI
script is just one command line option away. But it does require Plack
to be installed... well, on the other hand the modified gitweb needs
FCGI module to be ran as FastCGI script, which is not a CORE Perl module
either.
I also wonder how running via wrapper script affect performance, as
compared to modified gitweb running as FastCGI script, using CGI::Fast
and FCGI.
P.S. A bit of history: original patch by Sam Vilain adding FastCGI
support by using CGI::Fast is from 2006. Eric Wong patch adding
gitweb.fcgi wrapper (with 'no warnings; do $file' instead of modern
CGI::Compile->compile($file)) is from 2007.
I have originally replaced 'exit' in die_error() subroutine by non-local
jump to the end of request processing in ultimately a bit failed attempt
to use die_error() in CGI::Carp::set_message(), because when using
'exit' the error didn't get logged (unfortunately you can set error
message, but you can set HTTP headers for error message this way).
I have then noticed that this change would also allow to add FastCGI
support to gitweb in a very simple way. Therefore I have ported Sam
Vilain patch to modern gitweb codebase. Well, it did require some
restructuring of gitweb code (some refactoring), so it wasn't that
simple... nevertheless I think that this refactoring is mainly a good
change anyway.
P.P.S. One of constraints to gitweb development is that it should run
with minimal set of non-core modules. Some people even complain that
gitweb (or was it about git in general?) requires at least Perl 5.8.6 or
about (because of Encode module and Unicode support).
If one wants Modern Perl git web interface, there is always Gitalist...
--
Jakub Narebski, Poland
ShadeHawk on #git at FreeNode
jnareb on #plack at irc.perl.org
next prev parent reply other threads:[~2010-05-10 21:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <g2s693254b91005091428ib188cbd1le5ffa90eace741a8@mail.gmail.com>
2010-05-09 23:05 ` gitweb, FastCGI and PSGI/Plack Jakub Narebski
2010-05-10 0:59 ` Tatsuhiko Miyagawa
2010-05-10 16:26 ` Jakub Narebski
2010-05-10 17:14 ` Tatsuhiko Miyagawa
2010-05-10 1:05 ` Tatsuhiko Miyagawa
2010-05-10 10:32 ` Jakub Narebski
2010-05-10 17:03 ` Tatsuhiko Miyagawa
2010-05-10 18:40 ` Jakub Narebski
2010-05-10 18:43 ` Tatsuhiko Miyagawa
2010-05-10 21:10 ` Jakub Narebski [this message]
2010-05-11 0:07 ` Tatsuhiko Miyagawa
2010-05-11 9:29 ` Jakub Narebski
2010-05-11 9:44 ` Peter Vereshagin
2010-05-11 18:56 ` Tatsuhiko Miyagawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201005102310.47879.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=jgoerzen@complete.org \
--cc=juanjo@comellas.org \
--cc=miyagawa@gmail.com \
--cc=normalperson@yhbt.net \
--cc=pasky@suse.cz \
--cc=peter@vereshagin.org \
--cc=sam.vilain@catalyst.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).