7 ms·

> 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

> 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/e3e756cf1eebe883ee57bb1ab537047b05f70727 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 http://www.slideshare.net/miyagawa/plack-at-oscon-2010 - miyagawa

bbbbbbbbb 15y ago
Thank you for trying to sort it out. > I assume you're looking at the non-dev PSGI specification yes. > PSGI specification on CPAN Not really sure it is a good idea to put a spec on CPAN(I know you can find books on CPAN but I really do not think this is the right place for such matters but especially when PSGI/Plack confusion certainly exists.well, that just my view of things)... Regarding your additions: >You can stop writing code to support many web server environments. As your slide shows, 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. The perl based server you list were built for PSGI in mind so you sell me some candies and the toothbrush that goes with it. > Your framework can now use all of Plack middleware components. 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. Some of these PSGI middleware were extracted from Catalyst. Catalyst authors decided to create their own set of engine instead of choosing to use CGI.pm (unlike CGI::Application/Jifty building upon it), linking to your "gross." conclusion- in your slide. > You can test the application using the consistent L<Plack::Test> interface. 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) Regarding your slide: The diagram you show is at best simplistic, at worst wrong (factcgi->lighttpd). It deviates from reality to get to your point. I find the "CGI.pm? meh" slide very disrespectful and all by itself shows the ambient snobbish attitude towards this very useful module(inherited from the Catalyst community mindset?) so all in all, I still don't get the problem it is trying to solve(stealing from python you wrote. an other language, an other culture, an other context) I still don't get the benefit out of it and why I should use it. I think I am a lost cause^^; I am sorry. It's not that I am against new things but here, I really don't get the advantage of this spec and everything that goes around. I have a bootstrap package that launches the FastCGI run loop then delegates to modules that do there job and print the resulting body at the very end (it's a MVC like framework,nothing fancy) so I don't think it would hurt much to add support for this but I won't do so as long as I don't get a real + in doing so. Using Nginx is not much of a matter. (Nginx+FastCGI should be fine)
- bulknews 15y ago
  > 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 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.
  - bbbbbbbbb 15y ago
    >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!

bbbbbbbbb 15y ago

Thank you for trying to sort it out. > I assume you're looking at the non-dev PSGI specification yes. > PSGI specification on CPAN Not really sure it is a good idea to put a spec on CPAN(I know you can find books on CPAN but I really do not think this is the right place for such matters but especially when PSGI/Plack confusion certainly exists.well, that just my view of things)... Regarding your additions: >You can stop writing code to support many web server environments. As your slide shows, 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. The perl based server you list were built for PSGI in mind so you sell me some candies and the toothbrush that goes with it. > Your framework can now use all of Plack middleware components. 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. Some of these PSGI middleware were extracted from Catalyst. Catalyst authors decided to create their own set of engine instead of choosing to use CGI.pm (unlike CGI::Application/Jifty building upon it), linking to your "gross." conclusion- in your slide. > You can test the application using the consistent L<Plack::Test> interface. 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) Regarding your slide: The diagram you show is at best simplistic, at worst wrong (factcgi->lighttpd). It deviates from reality to get to your point. I find the "CGI.pm? meh" slide very disrespectful and all by itself shows the ambient snobbish attitude towards this very useful module(inherited from the Catalyst community mindset?) so all in all, I still don't get the problem it is trying to solve(stealing from python you wrote. an other language, an other culture, an other context) I still don't get the benefit out of it and why I should use it. I think I am a lost cause^^; I am sorry. It's not that I am against new things but here, I really don't get the advantage of this spec and everything that goes around. I have a bootstrap package that launches the FastCGI run loop then delegates to modules that do there job and print the resulting body at the very end (it's a MVC like framework,nothing fancy) so I don't think it would hurt much to add support for this but I won't do so as long as I don't get a real + in doing so. Using Nginx is not much of a matter. (Nginx+FastCGI should be fine)

bulknews 15y ago
> 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 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.
- bbbbbbbbb 15y ago
  >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!