bulknews

slightly more credible source - his attorney on winny's case confirmed he passed away 7/6 6:55 pm JST due to a heart attack. http://danblog.cocolog-nifty.com/index/2013/07/post-9e47.htm...

Well, I take "insane" as a compliment :) While it is true you can emulate the traffic by looking at web server logs, it was crucial for us to send the exact same request including the same HTTP headers and request body (think POST requests), in real time with the same access pattern.

It was easier for us to write EM based proxy like this than writing a web server plugin that does it, etc.

Yep, we run kage behind another load balancer that does SSL decryption etc.

Yeah good point. We actually run kage proxy behind another load balancer, and only send traffic with a sampling cookie set, which can be controlled from our main app.

> - Why send back an array ref instead of using the CGI way? What is the advantage it brings?

If you design a fibonacci() function, would you make it print the result to STDOUT, or return the result as a return value?

If the specification is to print to STDOUT, a web server needs to make a trick to capture the output using tie, PerlIO or anything else, just like FCGI.pm does, and that's inefficient.

> - Are all the $ENV variables available? (SCRIPT_NAME for example?)

http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI.pod#The_Envi...

> I don't really see what advantages it will bring to framework like Mojolicious for example (they will certainly never ever used any Middleware stuff from the Plack namespace as this is at the heart of their policy

See this post by the Mojolicious author, how to use Plack middleware for ANY Mojolicious based apps http://blog.kraih.com/mojolicious-and-plack

Also for Dancer: http://advent.perldancer.org/2010/22

> while (my $req = CGI::Fast->new) { myApp->run($req); } > Is there a handler/wrapper for that?

Assuming that while loop is in your bootstrap FastCGI script, you can instead have an app.psgi (or whatever named) file with the content:

    use CGI::PSGI;
    my $app = sub { my $req = CGI::PSGI->new(shift); myApp->run_psgi($req) };

For most web frameworks, the change should be minimal and straightforward: for example, CGI::Application needed less than 10 lines of code to implement this. http://search.cpan.org/~markstos/CGI-Application-PSGI-1.00/

(I implemented the original code, and markstos, the maintainer of CGI.pm and CGIApp now took it over. As you can see there's a small hack to capture the output - they're working on removing this hack by implementing the PSGI natively inside the CGIApp codebase)

> WebGUI discovered FastCGI via a PSGI implementation but it's FastCGI who brought the speed,

No, they got a performance boost with our preforking standalone HTTP server, which is currently called Starman, not just FastCGI.

Speaking of FastCGI, although Plack has a FCGI.pm-based FastCGI handler, i've been working on another FastCGI based preforking PSGI server called fastpass. https://github.com/miyagawa/fastpass

It is XS dependency free (unlike FCGI.pm and CGI::Fast) and the performance is still the same with FCGI.pm, roughly like 4000 requests per second on my laptop, with a simple HelloWorld app via an nginx frontend. I guess we could do even better by doing optional XS parsing with pure perl fallback as well.

FWIW for a comparison, with Starman I get 7k and Feersum gets 9k requests per second on the same machine. (Of course the number is not that significant since in the real world, your application does more IOs, templating stuff and database handling, and the qps would be much smaller)

Again, the nice thing about all of these things is that your code, and everyone else's code, don't need any line of code change to support this new server, once you get PSGI.

> In the meantime, I will try to play with it on my spare time. I guess it will be the easiest way to discover what I might be missing...

I'm pretty sure you will :)

> By the way, adding some script examples for CGI::PSGI and other related modules would be much appreciated (The doc is too elliptic and assume we know already that much about the PSGI context and Plack system)

The SYNOPSIS has the complete working example code that you can run with plackup, or any PSGI compatible web server - there's no much need for detailed docs about the interface since you don't need to change anything, other than actually being documented.

That said, a doc patch is always welcome - on github fork or via RT.

For the last chance, I'd suggest you more links where people explain the benefit of PSGI over CGI, Apache, FastCGI, HTTP::Engine or anything - in case you haven't checked them out. If you still don't get it and think Apache + FastCGI + CGI::Fast is the best thing in the world and you absolutely need nothing else, then I'm sorry, but that's fine.

http://www.perl.org/about/whitepapers/perl-plack.html http://www.simon-cozens.org/content/i-finally-get-psgi-and-p... http://blog.patspam.com/2009/plebgui-webgui-meets-plack

> Not really sure it is a good idea to put a spec on CPAN

They are also available on github with POD markup, with the full version controlled history: https://github.com/miyagawa/psgi-specs

> CGI.pm handles quite well many of the environment you list. It has been in development for more than 10years, updated very regularly to fix bugs, even browser based one, the doc is easy to read.

Yes, that's why I collaborated with CGI.pm authors and maintainers (Lincoln Stein and Mark Stosberg) from day 1 - like the possibility to include PSGI support directly into CGI.pm, which ended up in an extension module i co-authored with CGI.pm maintainers and put up on CPAN as CGI::PSGI, the CGI.pm compatible interface. T

There's also CGI::Emulate::PSGI which allows to write any CGI scripts unmodified under the PSGI environment.

> session, caching,etc. All of these "middleware" already exists since a very long time. so it is just yet an other addition,an other way of doing it.

It's not just an "addition" - if there are N frameworks, the caching modules need to be written and maintained for N frameworks - with PSGI unification, it should be written once and tested and maintained once - that way we can avoid duplicate efforts to fix bugs and make improvements, etc.

> Catalyst authors decided to create their own set of engine instead of choosing to use CGI.pm (unlike CGI::Application/Jifty building upon it)

and the upcoming Catalyst 5.9 removes all engines in favor of PSGI/Plack interface, like Jifty did a while ago.

> WWW::Mechanize works like a charm for such matters. (perhaps your Plack::Test differs though, did not look into it so this might be a valid point)

That's why there's Test::WWW::Mechanize::PSGI exists - you can run the exactly same test against a live server as well as in-process testing through the PSGI interface.

> the doc is unclear as to what it brings on the table, why it should be used, how to be used, the improvement it brings if any are really not clear.

I assume you're looking at the non-dev PSGI specification on CPAN. We're working on revising the documentation to upgrade the specification to 1.1, as well as improving the FAQ document.

Just to address your concern, I improved the part where it explains the benefits of switching to PSGI: https://github.com/miyagawa/psgi-specs/commit/e3e756cf1eebe8...

Also, for more generic overview and introduction of what PSGI is and why it is useful, take a look at my slides at OSCON 2010: http://www.slideshare.net/miyagawa/plack-at-oscon-2010

- miyagawa