5 ms·

>They are also available on github Great. perhaps getting rid of it on CPAN could be nice. > It's not just an "addition" - if there are N frameworks, the cach

>They are also available on github Great. perhaps getting rid of it on CPAN could be nice. > It's not just an "addition" - if there are N frameworks, the caching modules need to be written and maintained for N frameworks I can not agree with that point. You are almost forgetting CPAN here-which is funny coming from you- (The strength of Perl that many languages do not even dream to have)... The actual modules were context agnostic and it's not because you have N frameworks that you MUST have N xxx(caching,session) frameworks. It's just that some framework authors want to reinvent the wheel.no more, no less(in other languages, without an infrastructure like CPAN this can happen more than it ought to, indeed!). so the logic: N web framework = N xxx sub frameworks is just biased. It has always been possible to not duplicate efforts, avoid bugs with different code trying to solve the same problem. It's just that again, some framework did reinvent the wheel where they should have been using what already works (or help on it). > That's why there's Test::WWW::Mechanize::PSGI exists you are just telling me that there is yet an other way of doing the same thing but in the PSGI environment. All in all, I still don't see what the PSGI spec/protocol and the modules that evolute around bring to the environment. I don't see why we should have a superset of CGI,which is a language agnostic protocol,that binds with Perl via PSGI. Really don't get the idea...Is this binding between Perl and the protocol lead to way much better performance?(better than FastCGI?) I've never used mod_perl as it is only useful for Apache but I knew that using FastCGI could open me many servers and better performance without having to change much and care about even the language. I guess my environment is too far from the problems you seem to encounter and fix. They are new things where I think, yes, this is going to be good but here, the "pintokita" moment does not arrive at all. I can only hope that DotCloud will offer a simple support for fastCGI (CGI::Fast) with Nginx. 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) Thank you for your time and efforts anyhow!

bulknews 15y ago
> 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.perl.org/about/whitepapers/perl-plack.html http://www.simon-cozens.org/content/i-finally-get-psgi-and-plack http://www.simon-cozens.org/content/i-finally-get-psgi-and-p... http://blog.patspam.com/2009/plebgui-webgui-meets-plack http://blog.patspam.com/2009/plebgui-webgui-meets-plack
- bbbbbbbbb 15y ago
  > That said, a doc patch is always welcome - on github fork or via RT. I would like to but I need to understand how this works to provide any patch whatsoever. What about porting a CGI::Fast application into the PSGI stack then? while (my $req = CGI::Fast->new) { myApp->run($req); } Is there a handler/wrapper for that? I've read all the articles but it did not help much. WebGUI discovered FastCGI via a PSGI implementation but it's FastCGI who brought the speed, not PSGI per se. So it brings me back to my point... > think Apache + FastCGI + CGI::Fast is the best thing in the world and you absolutely need nothing else I think FastCGI was there to solve indeed a problem and did quite well at doing so. It could be Apache/Nginx/IIS + FastCGI&CGI::Fast, it would work too (Apache/IIS is from experience but Nginx is just an educated guess). I've decided a long time ago that I will never go the mod_perl way (or at least, will not use their low level access API) then switched to FastCGI and been happy since then. I still don't get it but perhaps one day it will hit me. I guess when somebody will bring a "Middleware" that will meet a need. 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... If DotCloud does not offer this infrastructure(Nginx+FastCGI), it's ok, I still can use our actual providers and it will work (exactly the WebGUI article example for cheap providers!) Thank you for your time!
  - bulknews 15y ago
    > 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) }; Now your new `run_psgi()` method should return the [ $status, $headers, $body ] array reference, instead of printing them to the STDOUT. And then the app.psgi can be run from CGI, FastCGI, mod_perl, Starman, Twiggy or whatever PSGI supported web servers. 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/ 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 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 :)

bulknews 15y ago

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

bbbbbbbbb 15y ago
> That said, a doc patch is always welcome - on github fork or via RT. I would like to but I need to understand how this works to provide any patch whatsoever. What about porting a CGI::Fast application into the PSGI stack then? while (my $req = CGI::Fast->new) { myApp->run($req); } Is there a handler/wrapper for that? I've read all the articles but it did not help much. WebGUI discovered FastCGI via a PSGI implementation but it's FastCGI who brought the speed, not PSGI per se. So it brings me back to my point... > think Apache + FastCGI + CGI::Fast is the best thing in the world and you absolutely need nothing else I think FastCGI was there to solve indeed a problem and did quite well at doing so. It could be Apache/Nginx/IIS + FastCGI&CGI::Fast, it would work too (Apache/IIS is from experience but Nginx is just an educated guess). I've decided a long time ago that I will never go the mod_perl way (or at least, will not use their low level access API) then switched to FastCGI and been happy since then. I still don't get it but perhaps one day it will hit me. I guess when somebody will bring a "Middleware" that will meet a need. 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... If DotCloud does not offer this infrastructure(Nginx+FastCGI), it's ok, I still can use our actual providers and it will work (exactly the WebGUI article example for cheap providers!) Thank you for your time!
- bulknews 15y ago
  > 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) }; Now your new `run_psgi()` method should return the [ $status, $headers, $body ] array reference, instead of printing them to the STDOUT. And then the app.psgi can be run from CGI, FastCGI, mod_perl, Starman, Twiggy or whatever PSGI supported web servers. 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/ 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 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 :)