4 ms·

Dancer and Mojolicious are pretty new and I will not use them in production yet (not to say that our framework is better, way from that but just that it's not o

Dancer and Mojolicious are pretty new and I will not use them in production yet (not to say that our framework is better, way from that but just that it's not open to things like that: http://blog.kraih.com/mojolicious-116-emergency-release-please-upgr http://blog.kraih.com/mojolicious-116-emergency-release-plea...). Catalyst is a dependency hell made true,not for us either. Mojolicious and Dancer will certainly be nice and will look into it but not at this stage of development. >Some might say that it's a bit experimental, Because it is. It's nice to play with it though. But not quite yet to use for our clients. > but the authors are awesome people, always willing to fix bugs as fast and efficiently as possible. Won't be able to say to my client: well, you know, we've tried this experimental stuff but we met these bugs we can't do anything about. "hey, what about FastCGI?" This was a very good question and I would have answered go for it... Apache+FastCGI+CGI::Fast. That's quite common nowadays and I think well understood, well documented. cpanm is not necessary, I've never used it and am happy with cpan. oh, right, cpanm is by the same author right? perlbrew&locale::lib are nice things to have though. > We would like to help and see how we can get it to run on DotCloud! Apache+FastCGI+CGI::Fast,that will do for me. Apache+mod_perl,that will do (even though i don't use it). Having at the cutting edge technologies is nice, don't get me wrong but it would help to have at least a more stable or at least bullet-proof environment too.

whiskeyjack 15y ago
I resepectfully disagree. My company has two PSGI Dancer apps running mission critical elements. They're "new" but they're absolutely production ready. Plack/PSGI has been embraced by almost everyone. I'm REALLY looking forward to playing with DotCloud. Plack/PSGI is not "cutting edge". It's the way to do it now, not tomorrow. You do Miyagawa a disservice implying he's pumping his own code.
- nmcfarl 15y ago
  Likewise my company is 100% PSGI for the last year+, we're a mix of a good number of Catalyst and Dancer apps. We've had absolutely 0 problems here. PSGI stable, sane and the way you want to be doing things.
  - bbbbbbbbb 15y ago
    As both of you have a good experience of Plack/PSGI, could you sum up the benefit you got from using it?
    - askbjoernhansen 15y ago
      If your app (or your framework) runs on Plack/PSGI you have a wide choice of server implementations. It will work under mod_perl, FastCGI and numerous other server environments. Indeed if you write an app to run on DotCloud; you can also run the same app on your laptop, Phenona, any other server -- etc etc. As someone else said (more politely), you'd have to be nuts to do an HTTP app now and not take advantage of it.
- bbbbbbbbb 15y ago
  >Plack/PSGI has been embraced by almost everyone. In your company or in general? Because if it's in general, I would be more than happy to see where you get your stats. > You do Miyagawa a disservice implying he's pumping his own code. Well, I do think that a not even 2yo spec,a set of modules that are 6~18 months old pushed on a cloud service like that with no back up plan for more "traditional" systems is a way to push its own system. we can agree to disagree on that. which percentage of providers offer plack with nginx nowadays compared to Apache with FactCGI?
mst 15y ago
If you have a problem with Catalyst dependencies, please report them to irc.perl.org #catalyst (I'm mst on there). Any time anybody reports a problem with them, we go out of our way to solve it - avoiding wheel reinvention is important to us to speed development but we understand that using a module makes us responsible for it installing for end users. if you really want CGI.pm, there are Plack modules to convert a PSGI environment to a CGI environment - descended roughly from the Catalyst::Controller::WrapCGI that Opsview sponsored Shadowcat to write years ago. And remember, PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think.
- bbbbbbbbb 15y ago
  >PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think. I see. Perhaps my vision of the state of PSGI is not right indeed. Nethertheless, my apps run under Fast::CGI and I really don't see the advantage of PSGI.

whiskeyjack 15y ago

I resepectfully disagree. My company has two PSGI Dancer apps running mission critical elements. They're "new" but they're absolutely production ready. Plack/PSGI has been embraced by almost everyone. I'm REALLY looking forward to playing with DotCloud. Plack/PSGI is not "cutting edge". It's the way to do it now, not tomorrow. You do Miyagawa a disservice implying he's pumping his own code.

nmcfarl 15y ago
Likewise my company is 100% PSGI for the last year+, we're a mix of a good number of Catalyst and Dancer apps. We've had absolutely 0 problems here. PSGI stable, sane and the way you want to be doing things.
- bbbbbbbbb 15y ago
  As both of you have a good experience of Plack/PSGI, could you sum up the benefit you got from using it?
  - askbjoernhansen 15y ago
    If your app (or your framework) runs on Plack/PSGI you have a wide choice of server implementations. It will work under mod_perl, FastCGI and numerous other server environments. Indeed if you write an app to run on DotCloud; you can also run the same app on your laptop, Phenona, any other server -- etc etc. As someone else said (more politely), you'd have to be nuts to do an HTTP app now and not take advantage of it.
bbbbbbbbb 15y ago
>Plack/PSGI has been embraced by almost everyone. In your company or in general? Because if it's in general, I would be more than happy to see where you get your stats. > You do Miyagawa a disservice implying he's pumping his own code. Well, I do think that a not even 2yo spec,a set of modules that are 6~18 months old pushed on a cloud service like that with no back up plan for more "traditional" systems is a way to push its own system. we can agree to disagree on that. which percentage of providers offer plack with nginx nowadays compared to Apache with FactCGI?

mst 15y ago

If you have a problem with Catalyst dependencies, please report them to irc.perl.org #catalyst (I'm mst on there). Any time anybody reports a problem with them, we go out of our way to solve it - avoiding wheel reinvention is important to us to speed development but we understand that using a module makes us responsible for it installing for end users. if you really want CGI.pm, there are Plack modules to convert a PSGI environment to a CGI environment - descended roughly from the Catalyst::Controller::WrapCGI that Opsview sponsored Shadowcat to write years ago. And remember, PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think.

bbbbbbbbb 15y ago
>PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think. I see. Perhaps my vision of the state of PSGI is not right indeed. Nethertheless, my apps run under Fast::CGI and I really don't see the advantage of PSGI.