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)
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!
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-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.
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.
>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.
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.
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.
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?
By the way, I see that you've decided to go with Nginx as the primary server for all languages and this is not really a problem in fact. I don't think switching to Nginx would be much of a hassle.
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)