One of the main reasons, for me at least, will be the ability to add
SSL capabilities to a site. CherryPy does not support SSL.
Bingo. This is one of the main reasons.
Another reason may be to integrate your turbogears app with an
existing site that runs PHP. Since you can't run two servers on the
same port and running a public service on a non-standard port is...
well... non-standard, proxying/WSGI/SCGI is the way to go.
In addition to all of the above, I like it for the following reasons:
1. Deploying your application as a WSGI application allows you
to take advantage of all of the great WSGI middleware that
is starting to crop up.
2. Using SCGI means that you aren't running behind a threaded
python-based web server. I don't want to get into too many
religious wars here, but a forking server should be much much
faster than a proxy to a threaded python server. If the built
in web server was asyncore-based, I might change my tune here,
but I still like the separation of concerns that SCGI brings.
Ideally, I would like it to work like the Ruby on Rails FastCGI
dispatcher, so that you don't have to run a CherryPy server at all.
The web server would just fire-up processes as it needed them, and it
would handle all of the load balancing, etc. This makes it a lot
easier to scale, and a TON easier to configure. I don't know enough
about the internals of CherryPy to know if this is feasible. Kevin,
do you know?
TurboGears is pretty great, and is moving forward very quickly, but I
think deployment is still a place where it could be improved.
Kevin, you mentioned that Python Paste is included with TurboGears.
Does it include its own SCGI server that could be used in place of
flup? I couldn't figure out how to use Paste with TurboGears. Maybe
Ian Bicking could chime in here with how Paste could be integrated
into TurboGears?
-- Jonathan
