5 ms·

I don't really see how this would help. Thats what FastCGI is for. You would have to be dumb to expose a php internal HTTP server to the world, and configuring

I don't really see how this would help. Thats what FastCGI is for. You would have to be dumb to expose a php internal HTTP server to the world, and configuring a FastCGI backend is no harder than setting up a HTTP backend in apache/nigix/whatever. If its just for testing, most apache installs come with PHP by default, its just another command to learn.

ary 16y ago
That's not exactly true. You still need an HTTP server to proxy to the FastCGI back-end. This could be useful for a number of things outside of local development instances. One could avoid having to setup Apache/nginx/whatever to pick up the HTTP request from a reverse proxy and instead just spin up PHP on its own.
3dFlatLander 16y ago
It's even easier now that PHP 5.3.3+ has FPM included (config option is --enable-fpm). Getting it set up with nginix is a breeze.
- X-Istence 16y ago
  PHP FPM is nice and all, but the issue still is that it is a FastCGI server, so you need something that can route to it. This php -S proposal doesn't have that requirement.
Toucan 16y ago
The idea isn't to open the server to the world. The RFC states that it's meant to be used in a similar way to django's manage.py runserver, for development and internal testing. Django phrase it in their tutorial as: "We've included this with Django so you can develop things rapidly, without having to deal with configuring a production server -- such as Apache -- until you're ready for production. Now's a good time to note: DON'T use this server in anything resembling a production environment. It's intended only for use while developing. (We're in the business of making Web frameworks, not Web servers.)" As long as the PHP documentation includes similar caveats and guidance, an HTTP server isn't a bad thing.
- Legion 16y ago
  Yeah, the first thing I thought of when reading this was Ruby's WEBrick and how it's used in Rails to provide an out-of-the-box local development server. Don't see how that would be a bad thing. Something simpler and quicker than installing XAMPP or configuring the webserver that comes with your OS/distro.
abredow 16y ago
Seems like the built in server would be most useful for newbies to get an application running. Think if how much easier it is to get a basic Rails app running to start learning compared to configuring Apache and PHP together.
- al_james 16y ago
  Normally you just install apache and php and they just work. Macs come with both pre-installed as do most linux distros. Don't see whats so hard!
  - abredow 16y ago
    It isn't too hard for someone who is already familiar Apache. On OS X, mod_php is not enabled by default, requiring new users to dig in and learn about apache config files and document roots. I'm not saying it is difficult, and it is obviously important to learn, but it would be nice to be able to have a 1 page "get started with PHP" tutorial.
- sinaiman 16y ago
  Having webrick out of the box was awesome when I first started using Rails. The big difference, however, is that Rails includes a web server because Rails is a framework for developing web applications, while this proposal seems to want a web server included as part of the PHP distributable. PHP isn't exclusively used for web applications, so I don't think it makes too much sense IMO.

ary 16y ago

That's not exactly true. You still need an HTTP server to proxy to the FastCGI back-end. This could be useful for a number of things outside of local development instances. One could avoid having to setup Apache/nginx/whatever to pick up the HTTP request from a reverse proxy and instead just spin up PHP on its own.

3dFlatLander 16y ago

It's even easier now that PHP 5.3.3+ has FPM included (config option is --enable-fpm). Getting it set up with nginix is a breeze.

X-Istence 16y ago
PHP FPM is nice and all, but the issue still is that it is a FastCGI server, so you need something that can route to it. This php -S proposal doesn't have that requirement.

Toucan 16y ago

The idea isn't to open the server to the world. The RFC states that it's meant to be used in a similar way to django's manage.py runserver, for development and internal testing. Django phrase it in their tutorial as: "We've included this with Django so you can develop things rapidly, without having to deal with configuring a production server -- such as Apache -- until you're ready for production. Now's a good time to note: DON'T use this server in anything resembling a production environment. It's intended only for use while developing. (We're in the business of making Web frameworks, not Web servers.)" As long as the PHP documentation includes similar caveats and guidance, an HTTP server isn't a bad thing.

Legion 16y ago
Yeah, the first thing I thought of when reading this was Ruby's WEBrick and how it's used in Rails to provide an out-of-the-box local development server. Don't see how that would be a bad thing. Something simpler and quicker than installing XAMPP or configuring the webserver that comes with your OS/distro.

abredow 16y ago

Seems like the built in server would be most useful for newbies to get an application running. Think if how much easier it is to get a basic Rails app running to start learning compared to configuring Apache and PHP together.

al_james 16y ago
Normally you just install apache and php and they just work. Macs come with both pre-installed as do most linux distros. Don't see whats so hard!
- abredow 16y ago
  It isn't too hard for someone who is already familiar Apache. On OS X, mod_php is not enabled by default, requiring new users to dig in and learn about apache config files and document roots. I'm not saying it is difficult, and it is obviously important to learn, but it would be nice to be able to have a 1 page "get started with PHP" tutorial.
sinaiman 16y ago
Having webrick out of the box was awesome when I first started using Rails. The big difference, however, is that Rails includes a web server because Rails is a framework for developing web applications, while this proposal seems to want a web server included as part of the PHP distributable. PHP isn't exclusively used for web applications, so I don't think it makes too much sense IMO.