沉思WSGI

Limodou 问题

limodou <[email protected]>
reply-to        [email protected]
to      "Python.cn@google" <[email protected]>
date    Thu, Dec 25, 2008 at 10:59
subject [CPyUG:74762] WSGI的问题集

希望对wsgi了解的介绍下：

WSGI的app之间如何传递消息？在environ中添加吗？
多个app之间通过wsgi方式来工作，一般是怎么被调用的？它们的调用如何实现配置化？
对于request, response这样的东西如何在wsgi中处理，如何传递？是每次通过environ直接生成吗？如:

request = Request(environ)

这样做，会不会有效率问题。另外如何处理request中动态添加的属性，丢失吗？

集锦

WSGI的app之间如何传递消息

Limodou

def configure(app):
   return ErrorHandlerMiddleware(
           SessionMiddleware(
            IdentificationMiddleware(
             AuthenticationMiddleware(
              UrlParserMiddleware(app))))))

因此出现了paster，在每个app程序中添加：

def app_factory(global_config, **local_config):
   return application

然后通过paster来管理这些app的执行顺序。这样每个app还可以有自已的配置参数。这样就可以理解为什么tg和pylons要使用paster了。不过对我来说的确是理解复杂。甚至象pkg_resources的使用也是最近才一点点理解并开始使用的。

Qiangning Hong

WSGI的处理模式为 WSGI Server -> (WSGI Middleware)* -> WSGI Application
一次请求只有一个app。middleware和app之间通过environ交换消息。

YoungKing(Zopen.cn)

每个wsgi app是一个callable对象,传递两个参数，一个是environment ,一个是start_response 函数,
start_response这个函数用来response，
你在这里设置status和header，最后返回一个iterator(通常是字符串list)

多个app之间的调用

Qiangning Hong

同上，一个request最终落到一个app上。
不过每一个middleware对于调用者而言，接口和app是一样的。
一般在前端有一个appdispatcher通过URL选择执行哪一个app，可以是直接在WSGI Server里的代码指定，也可以这个dispatcher本身就是一个middleware。
Pylons使用的Routes这两种方式都支持。WSGI有一个route标准的草案。

request/response的WSGI 处置

Qiangning Hong

是的，webob其实就是怎么干的。
webob好像是用的lazy方式，初始化一个对象很轻量。如果要考虑效率问题，可以把生成的request对象也放在environ里面，之后的middleware和app就都可以直接使用了。Pylons是这样做的。
Limodou: 对于第三个问题，可能就与具体的框架相关了。目前不管是django也好，还是uliweb也好，其本上只有一个主wsgi应用在运行。不过因为uliweb的主要处理就是一个wsgi的app，所以是可以放在wsgi中进行使用的。
- Pylons是每一个Controller就是一个WSGI app。通过Routes来dispatch到某一个特定的controller运行

YoungKing(Zopen.cn)

在wsgi中,environment对应request,start_response对应response.envrionment中可以传任意python对象，这个比request方便多了.你可以修改envionment，把属性放到这里来

整体

Gu Yingbo <[email protected]

我认为wsgi的中间件倾向于做一些简单独立事情，每个中间件app 的依赖性比较低，
像werkzeug的DebuggedApplication这种风格就很好，一条语句就可以为一个wsgi应用添加一个调试界面。
我自己也就用中间件做一个请求的计时，sql语句调试开关这样简单的事情。
我觉得wsgi的最大好处是:
- 分离了服务器和应用的实现，
- 写一个wsgi应用就有一大把的部署方式，自己可以根据需要选择合适的。

for UliWeb

Limodou

谢谢，这下就清楚许多了。
按上面的回答，uliweb中的是Dispatcher(类名都是这么起的)，所以它本身是wsgi的。
在uliweb的前段时间，还可以通过config.py来添加在执行Dispatcher前的wsgi序列，不过现在去了，因为修改了许多地方，加回来也很容易。
因此我想uliweb会同时支持wsgi middleware和django-like middleware。
因为django-like middleware更多是在针对request, response的处理，目标比较统一。
对于wsgi的互用，我提第4个问题：
- 不同的wsgi middleware在不同的项目中是如何互用的？
  - 是不是目前都是需要基于paster才可以？有共它的方式，还是根本不存在问题。
  - 因为我看到paster是可以在创建wsgi middleware时引入一些local_conf的，这个倒是可以继续用，自已写一个简单的装入器。其它的有没有类似要依赖于paster的东西呢？

反馈

创建 by -- ZoomQuiet [DateTime(2008-12-25T04:10:48Z)]

PageComment2

[:/PageCommentData:PageCommentData]

WSGI/AskWSGI

沉思WSGI

Limodou 问题

集锦

WSGI的app之间如何传递消息

多个app之间的调用

request/response的WSGI 处置

整体

for UliWeb