[Web-SIG] wsgi layers
py-web-sig at xhaus.com
Tue Sep 7 13:06:20 CEST 2004
> Is my understanding correct in terms of layers
> A web browser sends requests to a WSGI enabled web server (eg
> mod_python under apache, or medusa or twisted) which passes them
> through installed WSGI middleware layers (eg session management,
> gzip, cookie consolidator etc) to an application hosted inside
> a WSGI enabled application framework (eg quixote).
I understand it differently, though perhaps wrongly.
I see that the request arrives to a web server, which is either a pure
python server, or a native-code server with a python interpreter and a
very thin WSGI adapter. This transforms the request into a WSGI
compatible request, and calls a single python application callable with
it, as specified under WSGI.
Possible server+adapter combinations would be
Apache + mod_python_wsgi
AnyServer + CGI + wsgi.py
SimpleHttpServerWSGI + Very little
Tomcat + modjy
Factored-out Medusa request dispatcher
PyWx+, FastCGI+, SCGI+, etc, etc, etc.
The single python application callable, I see as *being* the python
framework, e.g. WebWare. So all those server+adapter combinations listed
above basically become the bootstrap process by which HTTP requests are
fed to WSGI frameworks.
Hence, a fully-refactored-for-WSGI WebWare would then be portable to all
of the above server+adapter combinations (python 2.2+ accepted).
The WSGIWebWare application would then be responsible for driving the
request through a stack (more likely a tree) of middleware components,
based on its configuration.
So I suppose that I see middleware stacks/trees as the generic class of
python frameworks, and individual frameworks as instances of that class,
each with their own specific mechanisms for specifying configuration of
the stack/tree of middleware components.
To me, the portability of middleware would be ideally between
frameworks. For example, I could take the WebWare session management
middleware component and plug it into a Snakelets middleware stack. Or
more appropriately: don't make the Snakelets guy have to bend his brain
about session management and all of its horrors: just borrow and reuse
an existing quality and field-tested component. So, when I write about
middleware portability, this is what I mean, although that seems to
conflict with your picture of middleware happening outside the framework.
The difference between your picture and mine is that I don't see where
the middleware configuration happens in your processing model, i.e. how
is the stack of middleware components before the framework configured?
In the case of twisted or zope, I have to say that I'm not familiar
enough with the structure of either to know how exactly they would fit in.
But I know that an asynchronous WSGI server could be fairly easily put
together simply using asyncore. In this case, the application callable
could then be a simple dispatcher that sends WSGI requests down queues
into processing objects in other threads (which have been created by the
application callable at initialization time). The other-thread objects
receiving those requests from the queues could themselves drive the
requests through a stack of WSGI middleware. So the queues down which
requests are sent would simply be a mechanism for extending middleware
trees/stacks across thread boundaries (and potentially processor
boundaries in jython and ironpython).
> So the intention is that the application is written within the
> features of a specific WSGI enabled application framework while
> it can be hosted (via the way it's framework is WSGI compliant)
> in any WSGI server environment.
> If all this is so, then I am confused about which projects are
> currently implementing/planning to implement wsgi as servers and
> as application frameworks. My assumption is that the servers being
> pluggable don't need to be my first concern as long as there is
> something that can be used for testing. But the application
> framework is the critical one for application developers. What
> is the state of play here?
The above is my outline view of the topic. I think it would be great if
we could standardize on some terminology to be discussing these matters.
I found myself considering replacing the word "framework" with
"WebWare-like" up above, because the "f-word" is potentially
inappropriately used. From the middleware components point of view, the
framework is the WSGI server. From the server point of view, e.g.
mod_python, the framework is the WSGI application.
More information about the Web-SIG