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

[Ian Bicking]

Manlio Perillo wrote:
> Ian Bicking ha scritto:
>> Manlio Perillo wrote:
>> [...]
>>>
>>> As an example, in Paste you have choosed to using config dictionary 
>>> for middleware configuration, that is, you have middleware factories.
>>
>> I think this is a red herring.  WebOb specifically doesn't do anything 
>> related to configuration or the setup of the stack.  What it does do 
>> is stuff like:
>>
>> expires = http.format_time(0)
>> http.generate_cookie(
>>     environ, headers, name, '', expires=expires,
>>     domain=cookie_domain(environ), path=path,
>>     max_age=0)
>>
>> which would be resp.delete_cookie(name) (well, cookie_domain seems to 
>> be derived from a setting, but that's mostly unrelated).  This isn't a 
>> particularly substantial difference, but these small conveniences add up.
>>
> 
> As I have said, this is a personal taste, I don't like the 
> "architecture" used by WebOb and prefer to directly use the environ 
> dictionary without introducing other abstractions.
> This is possible, I'm writing a "not simple" application using wsgix.
> 
> 
> I'm still evaluating if I can reuse WebOb parsing functions (and this 
> would be a great thing: I think that we *really* need a package with 
> *only* low *level* parsing functions for the HTTP protocol).
> 
>  From what I can see, WebOb *does* not offer a low level interface for 
> the parsers: you *have* to use the Request object.
> 
> I really like multilevel architectures, instead.

This was the deliberate approach of Paste, and it does have several 
functions for doing things similar to how you describe.  As I said, I 
went down exactly this path, but I think WebOb solves the problem 
better.  You can think of WebOb as a way of currying functions.  All the 
request functions take an environ argument, curried through 
instantiation of webob.Request.  All response functions take 
status/headers/app_iter, curried through webob.Response.  State is never 
held outside the environment or the status/headers/app_iter of the response.

So think of webob.Request as the module of request-parsing routines, and 
webob.Response as the module of response-parsing routines.  (There are 
underlying functions for things like parsing dates, but they are only 
exposed through those classes.)

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org