[Web-SIG] Alternative to threading.local, based on the stack

[Manlio Perillo]

Ian Bicking ha scritto:
> Manlio Perillo wrote:

I'm adding web-sig in Cc.

>  [...]
>> I'm developing a WSGI framework with all these (and other) ideas:
>> http://hg.mperillo.ath.cx/wsgix
>>
>> Its still not documented, so I have not yet made an official 
>> announcement.
>>
>> The main design goal is to keep the level of the interface as low 
>> level as possible.
>>
>> I don't like additional interfaces (like Request and Response) objects 
>> around the WSGI dictionary, and I don't like frameworks like Django 
>> that completely hides the WSGI interface.
> 
> Have you tried webob?  My first run as Paste avoided wrappers around 
> those objects, but an object interface has been very helpful.
> 

I have not tried it, but I have read the code (as I have read the code 
of Paste).

In principle I'm against using additional interface, and one of the 
reason I wrote wsgix is to have a prof of concept, for trying to 
understand if it is feasible to write a WSGI application using an 
alternative framework.

wsgix (+ mod_wsgi for Nginx) has the same role as Paste, but I have 
decided to use a rather different approach.

As an example, in Paste you have choosed to using config dictionary for 
middleware configuration, that is, you have middleware factories.

In wsgix it is very different.
As an example:

http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/contrib/messages.py
http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/contrib/error_page.py

There are no factories.
The configuration is read (and globally cached) at request time from the 
environ dictionary.

With Nginx, configuration parameters can be defined in the server 
configuration.

There is an helper class:
http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/options.py
that helps with the parsing.

There is also a middleware:
http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/middleware.py

that reads the configuration from a YAML file, and merge it into the 
environ dictionary.


Of course it's all a matter of personal taste :).

The goal is to have the possibility to write "truly" reusable 
middlewares, that are easy to "plug" inside any WSGI server (almost all 
of configuration parameters have default values).




Manlio Perillo