Phil a écrit :
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

Seems correct.

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?

Yeps.

Does it just spawn a new thread for each
request?

Not AFAICT.


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?

I didn't bother reading Flup's source code, but I suppose this might be the case.

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.

Nor about which web server you use (Apache, lighthttpd, whatever).

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.

My humble opinion (based on years of experience in both Python and web programming) is that you're taking the wrong approach. I can only second Robert Kern here: use an existing, well maintained wsgi-compliant framework like Django, Pylons etc, and wait for the framework to be ported to python 3.x. Any other solution will almost certainly end up needing a complete rewrite anytime soon.

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.

Programming for the web - whatever the language & techno - indeed require a deep (or at least correct) understanding of HTTP and web servers, yes. Even with the abstraction layers provided by frameworks, you still need to understand how the whole damn thing works, what's an HTTP resquest & response and quite a few other things as well.

--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to