[Web-SIG] [ANN] twsgi: asynchronous WSGI implementation for Twisted Web
manlio_perillo at libero.it
Sun Apr 11 22:26:33 CEST 2010
Gustavo Narea ha scritto:
> Maybe I'm missing something obvious, but if the gateway doesn't support
> applications that return write() callables, then it's not WSGI.
> A callable that raises an exception does not even count. It's obvious
> that they must not raise exceptions -- Then what's the point of
> providing the callable?
Nothing is obvious in an official specification ;-).
The reason I choose to not completely remove the write callable is
because it will raise a nice error message if someone even try to use my
implementation to execute a WSGI application that requires the write
Moreover some middlewares or applications may assume the write callable
exists and the value returned by start_response is not None, even if it
is never used.
> That said, I *think* it might be OK to disable support for the write()
> callable *optionally* on a per application basis. For example, the
> gateway could look at the "requires_write" attribute of the application
> callable, if any:
> def wsgi_app(environ, start_response):
> # ... process the request and return a response....
> wsgi_app.requires_write = False
> That way, applications which don't use the write() callable can let your
> gateway know and thus it won't pass one on.
The problem is that applications that requires the write callable, are
not aware of this extension.
This is really a no problem, IMHO.
If you try to execute an application, and you get a NotImplementedError
extension, then you *know* that write callable is required.
Then, you just configure the WSGI gateway to use the required adapter.
for a pratical example using txwsgi.
With ngx_http_wsgi_module, you just have to add a
wsgi_middleware txwsgi.greenlet write_adapter;
directive in Nginx configuration file.
> We could even standardize this (at wsgi.org) so that any WSGI middleware
> which wraps an application can expose the "requires_write" attribute of
> the wrapped application... As long as such a middleware doesn't use
> write() either.
> On the other hand, I would avoid using "middleware" in this context for
> something specific to your implementation as people will believe it's a
> proper WSGI middleware.
I now use the term "adapter".
More information about the Web-SIG