At 05:40 PM 4/8/2010 +0200, Manlio Perillo wrote:
With WSGI 2.0 we will end up with:
- WSGI 1.0, a full featured protocol, but with hard to implement
middlewares
- WSGI 2.0, a simple protocol, with more easy to implement middlewares
but without support for some "advanced" applications
Let me see if I understand what you're saying. You want to support
suspending an application, without using greenlets or threads. Under
WSGI 1, you can do this by yielding empty strings before calling
start_response. Under WSGI 2, you can only do this by directly
suspending execution, e.g. via greenlet or eventlets or some similar
API provided by the server. Is this your objection?
As far as I know, nobody has actually implemented an async app
facility for WSGI 1, although it sounds like perhaps you're trying to
design or implement such a thing now. If so, then there's nothing
stopping you from implementing a WSGI 1 server and providing a WSGI 2
adapter, since as you point out, WSGI 2 is easier to implement on top
of WSGI 1 than the other way around.
(Note, however, that if you simply use a greenlet or eventlet-based
API for your async server, then the problem is neatly solved whether
you are using WSGI 1 or 2, and the effective API is a lot cleaner
than yielding empty strings.)
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
