Jonathan LaCour wrote:
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.
Can't you proxy from https to http? Assuming you feel the proxy
connection is secure -- and if you don't think a localhost connection is
secure, you might as well just give up ;)
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.
Of course, a WSGI HTTP server is also possible. However, there are no
forking WSGI HTTP servers that I know of, only threaded (the two
threaded are WSGIUtils based on BaseHTTPServer, and twisted.web2).
Well, I guess mod_python kind of qualifies as forking HTTP.
I think it's an easy win for CherryPy to just use WSGI for all serving,
and not maintain their own HTTP server (which I think is just another
BaseHTTPServer-based system).
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.
SCGI, compared to mod_python, means you aren't running in the Apache
process. I think there's a lot of advantages to that.
SCGI vs. HTTP proxy is mostly a matter of metadata, IMHO. SCGI gives
you more information about the request than HTTP -- not a lot, but a
little more. You (potentially) get the SCRIPT_NAME/PATH_INFO
distinction (to do this in HTTP some people have suggested
X-CherryPy-Root headers or something like that). And some variables
like REMOTE_USER can potentially be passed through, if you are doing
authentication in Apache (which is what I personally prefer to do). You
can do this with HTTP, but it's a lot more configuration.
SCGI is also easy to set up as a CGI script (cgi2scgi), which is
sufficiently fast (I'd guess half the speed of mod_scgi, but that's
easily lost in the noise of a real app).
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?
I've only successfully configured FastCGI once or twice. I'm sure it's
possible to do and maybe not that hard, *I've* just found it really
hard. And I don't think I'm the only one. As a simple protocol, maybe
not that big a deal -- and there's a flup FastCGI server as well.
Handling things like starting processes starts getting more complex (and
I don't think flup supports that mode), including a lot of complexity in
the configuration. But I hear both happy and unhappy reports.
Rails is starting to support SCGI now, I assume with a persistent
forking process started separately from the server. So, there must be
some reasons for that.
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?
Paste only includes glue for servers, including flup. I haven't made
the glue for SWAP yet, which is another SCGI server. I fiddled with
twisted.web2 glue as well, which is a threaded-only server which
supports both HTTP and SCGI.
Paste Deploy is a setup for configuring and deploying applications, and
is also related to all this, but SCGI or HTTP or whatever doesn't really
matter to it. Using Paste Deploy you'd set up a configuration file
describing the server (e.g., flup) and you'd set up a configuration file
describing all the applications you have installed (which might simply
be pointers to other configuration files, at least at this stage). The
rc scripts we use then run "paster serve --user=$APP_USER
--group=$APP_GROUP --daemon --log-file=$LOG_FILE --pid-file=$PID_FILE
$CONF_FILE", and all the applications are served in one process (which
can be forking). I've been thinking about making better CGI wrappers,
so you could do something like:
#!/usr/bin/env paster-cgi
...configuration file...
And then the configuration file itself would be a runnable CGI script.
If there are other cases I'd be happy to support them. But, for
instance, FastCGI confuses me ;) But if someone wants to explain it...
An Apache module would be cool too, something that would allow you to
give a Paste Deploy configuration file, and route it to mod_python.
This would probably be easy right now, using PythonHandler and a couple
other directives. An Apache module would just allow that to be a single
command.
*But*, right now CherryPy doesn't allow for multiple encapsulated
applications in the same process, so it doesn't fit well into Paste
Deploy :( If more people poke CherryPy people about this (ticket #145)
maybe that can be fixed.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
