[Web-SIG] wsgi layers

[Alan Kennedy]

[David Warnock]
 > 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.

Regards,

Alan.