On 2009-08-25 20:09 PM, Phil wrote:
I've seen lots of web sites explaining everything, but for whatever
reason I seem to not be picking something up.
I am a graphical person, which is probably the reason I haven't found
my answer.
May somebody please confirm if my diagram accurately represents the
stack, generally speaking.
http://i26.tinypic.com/1fe82x.png
Even if that is the case, I'm having a hard time understanding the
differences. I guess wsgiref has absolutely nothing to do with FCGI/
SCGI/CGI and simply receives and responds to HTTP requests following
the WSGI specification?
Correct.
Does it just spawn a new thread for each
request?
No, it is single-threaded.
If so, then how is this any different than a production
server with FCGI?
The way I am understanding the 'Production' side of that picture is
that the web server (eg. lighttpd) creates a single FCGI process. The
FCGI process is actually the entry point of the Framework/Application
which sets up Flup's WSGIServer, being the interface between FCGI and
the Framework/Application? What I mean is, it is just the code that
the web server loads to start with, example...
from flup.server.fcgi import WSGIServer
from app import application
WSGIServer(application).run()
... Then for each HTTP request, Flup's WSGIServer creates a new thread
to handle the request?
Something like that, yes.
As I've read elsewhere, "These days, FastCGI is never used directly.
Just like mod_python it is only used for the deployment of WSGI
applications." As far as I understand, the main (or only?) reasoning
for this is because WSGI makes Python applications easier to deploy
without having to worry about whether using FCGI/SCGI/CGI.
Yes, that is the primary reason for WSGI, in my mind. There are other things
like the composability of applications, but the decoupling of application
authoring from deployment is the sine qua non, in my opinion.
What would be involved to run Python on the web using FCGI without
WSGI? I can feel the flames already. This isn't the only reason I want
to know, but one reason is that I want to use Python 3.1 and as I
understand, this will have to wait for the WSGI 2.0 specification to
ensure time isn't wasted.
I am willing to bet that the FCGI libraries haven't been upgraded to Python 3.x,
either. I suspect that the most 3.x-updating work will be going into WSGI and
the adapters. E.g.
http://www.saddi.com/software/news/archives/64-Dabbling-in-Python-3.0.html
You may want to rethink the Python 3.x requirement, though. It will probably be
much less a waste of your time to write your app using a framework like Django
or Pylons on Python 2.x and then upgrade to Python 3.x when they do.
I apologize if the questions are ridiculous. I've just recently got
into web programming and it seems that in order for me to use Python,
I need a deep understanding of web servers, HTTP, FCGI, etc. I have
more questions but they go more off topic, so I will save it for
another thread, another day.
Knowing something about HTTP will certainly help get into the right mindset to
know what limitations and capabilities web apps can have.
Typically, though, you use a framework that abstracts most of this stuff away
from you. You usually only need to delve into the details in very specific
circumstances.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
