6 ms·

huh? - No Apache???? - why force a rather devish level PSGI module on all web applications???? oh, yeah, you've been advised by the guy who made the port...

huh? - No Apache???? - why force a rather devish level PSGI module on all web applications???? oh, yeah, you've been advised by the guy who made the port... i've been using CGI::Fast under Apache for years and it has been working just PERFECTLY fine. Do not see the need to change especially when the PSGI doc is so badly written... At least the doc states that people who supports mod_perl/CGI::Fast will not see much benefit of switching to PSGI... - what is the Perl version?

davecardwell 15y ago
5.12: https://gist.github.com/945834 https://gist.github.com/945834
- bbbbbbbbb 15y ago
  thank you! recent version, that's a plus.
shykes 15y ago
We expect our choice of stack to be transparent for all developers. If it turns out it's the wrong choice, we'll either switch to Apache, or at least support both. So far all alpha testers seemed very happy :)
- bbbbbbbbb 15y ago
  Well, I got the invitation and while playing around with nodejs, I was really looking forward for Perl support but this is absolutely not the environment I want to work on (wanted to use an in-house framework, not the ones listed and see if DotCloud could be of use for our clients). To tell the truth, this could be a good occasion to try to make the in-house app works in such environment but 1- don't see any real benefit 2- don't want to decipher the doc 3- no time (will have to work extra hours) you should definitely support both environment and not base your choice on the sole feedback of one person (you know... TMTOWTDI)
  - jpetazzo 15y ago
    Hi, Well, actually, we didn't pickup Plack from its author. When people started asking about Perl, we just replied with another question: "which framework? how? what?", and we tried extract the most common denominator. The vast majority told us about Mojolicious, Dancer and Catalyst. There seemed to be a pattern :-) Regarding the server interface, a lot of people seems to agree over Plack. We were the ones asking "hey, what about FastCGI?" - since I personally never had met Plack before. We were shown the Plack::*::FCGI modules and thought "okay, that seems cool". Then we had a look at the server options. We had already used UWSGI for the Python stack, and UWSGI has a PSGI module. Some might say that it's a bit experimental, but the authors are awesome people, always willing to fix bugs as fast and efficiently as possible. Of course, the author of Plack helped us to get everything straight - but paradoxally, he was also the one pointing us to cpanm, perlbrew and basic stuff like Makefile.PL. Now, to get back to you: what does your app look like? We would like to help and see how we can get it to run on DotCloud!
    - bbbbbbbbb 15y ago
      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.
perlgeek 15y ago
What's devish about PSGI? Seems like exactly the right choice for the task.
- bbbbbbbbb 15y ago
  Like FastCGI is... PSGI has been developed in 2009, then nothing for a long time (and as it hasn't spread as wild fire across providers i don't think there is enough real dev around it to assure that it is "stable" enough), now, a dev release, sure... 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... "you will be glad in the future..."...yeah, i need more than that to get people around me starting to use it. FastCGI has been working for a long time, clear, easy and already "cross-server"... All in all, the doc is a real problem and no hard evidence of it being used is, to some extend, an other.
  - mst 15y ago
    PSGI is not at the same level as FastCGI. Nobody in their right mind has been using CGI::Fast directly for years - we've done it via adapters through e.g. Catalyst::Engine::FCGI for Catalyst and equivalents for other frameworks. PSGI is just a means to present various HTTP bearing things to the app - in fact the FCGI.pm maintainers all now deploy their applications via Plack::Handler::FCGI. All perl frameworks of note now have support for PSGI, and Catalyst is dumping its engine modules in favour of Catalyst::Engine::PSGI - we've been heavily involved in improving the Plack ecosystem to ensure that'll be a sane choice. There's plenty of assurance that it's stable enough. Go DotCloud for forward thinking choices here.
    - bbbbbbbbb 15y ago
      > Nobody in their right mind has been using CGI::Fast directly for years Could you extend on that? Been using it for years,just works fine. >PSGI is just a means to present various HTTP bearing things to the app I really still don't get the benefit though. But perhaps I should dig into it more (for now, the python implementation doc was helpful but still did not bring me that much clues as to the real benefits about it)

davecardwell 15y ago

5.12: https://gist.github.com/945834 https://gist.github.com/945834

bbbbbbbbb 15y ago
thank you! recent version, that's a plus.

shykes 15y ago

We expect our choice of stack to be transparent for all developers. If it turns out it's the wrong choice, we'll either switch to Apache, or at least support both. So far all alpha testers seemed very happy :)

bbbbbbbbb 15y ago
Well, I got the invitation and while playing around with nodejs, I was really looking forward for Perl support but this is absolutely not the environment I want to work on (wanted to use an in-house framework, not the ones listed and see if DotCloud could be of use for our clients). To tell the truth, this could be a good occasion to try to make the in-house app works in such environment but 1- don't see any real benefit 2- don't want to decipher the doc 3- no time (will have to work extra hours) you should definitely support both environment and not base your choice on the sole feedback of one person (you know... TMTOWTDI)
- jpetazzo 15y ago
  Hi, Well, actually, we didn't pickup Plack from its author. When people started asking about Perl, we just replied with another question: "which framework? how? what?", and we tried extract the most common denominator. The vast majority told us about Mojolicious, Dancer and Catalyst. There seemed to be a pattern :-) Regarding the server interface, a lot of people seems to agree over Plack. We were the ones asking "hey, what about FastCGI?" - since I personally never had met Plack before. We were shown the Plack::*::FCGI modules and thought "okay, that seems cool". Then we had a look at the server options. We had already used UWSGI for the Python stack, and UWSGI has a PSGI module. Some might say that it's a bit experimental, but the authors are awesome people, always willing to fix bugs as fast and efficiently as possible. Of course, the author of Plack helped us to get everything straight - but paradoxally, he was also the one pointing us to cpanm, perlbrew and basic stuff like Makefile.PL. Now, to get back to you: what does your app look like? We would like to help and see how we can get it to run on DotCloud!
  - bbbbbbbbb 15y ago
    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.

perlgeek 15y ago

What's devish about PSGI? Seems like exactly the right choice for the task.

bbbbbbbbb 15y ago
Like FastCGI is... PSGI has been developed in 2009, then nothing for a long time (and as it hasn't spread as wild fire across providers i don't think there is enough real dev around it to assure that it is "stable" enough), now, a dev release, sure... 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... "you will be glad in the future..."...yeah, i need more than that to get people around me starting to use it. FastCGI has been working for a long time, clear, easy and already "cross-server"... All in all, the doc is a real problem and no hard evidence of it being used is, to some extend, an other.
- mst 15y ago
  PSGI is not at the same level as FastCGI. Nobody in their right mind has been using CGI::Fast directly for years - we've done it via adapters through e.g. Catalyst::Engine::FCGI for Catalyst and equivalents for other frameworks. PSGI is just a means to present various HTTP bearing things to the app - in fact the FCGI.pm maintainers all now deploy their applications via Plack::Handler::FCGI. All perl frameworks of note now have support for PSGI, and Catalyst is dumping its engine modules in favour of Catalyst::Engine::PSGI - we've been heavily involved in improving the Plack ecosystem to ensure that'll be a sane choice. There's plenty of assurance that it's stable enough. Go DotCloud for forward thinking choices here.
  - bbbbbbbbb 15y ago
    > Nobody in their right mind has been using CGI::Fast directly for years Could you extend on that? Been using it for years,just works fine. >PSGI is just a means to present various HTTP bearing things to the app I really still don't get the benefit though. But perhaps I should dig into it more (for now, the python implementation doc was helpful but still did not bring me that much clues as to the real benefits about it)