[Web-SIG] [RFC] x-wsgiorg.suspend extension
manlio_perillo at libero.it
Mon Apr 12 16:19:56 CEST 2010
Graham Dumpleton ha scritto:
>> Claiming that x-wsgiorg.suspend does not help writing portable WSGI
>> application is something similar (well, I'm a bit exaggerating here) of
>> saying that WSGI does not allow to write portable web applications,
>> because real world WSGI applications needs a database, a database
>> engine, and so on.
> It is not the same. I can take code using a specific database instance
> and still run that WSGI application, using the same database, on a
> different WSGI hosting mechanism without really changing anything
> about how I interact with the WSGI server and its request handling.
> The concern here is the WSGI interface and interacting with the web
> server, not other non related third party packages.
This is true.
However you can say the same for x-wsgorg.suspend extension.
As an example, you can have an application that use a standard event
API, and you can run it on several asynchronous WSGI implementations.
The difference is that here we speak about event API, and not specific
Note however that we can also speak about specific implementations.
As an example, I can implement Twisted reactor API in Nginx, so that
WSGI applications using Twisted API can be executed on both Twisted and
Nginx. I could do the same with libevent API. It's only a technical
> You are articificially adding something to the WSGI interface as an
> extension which is pointless. Since you are bound to the specific
> event loop of the underlying WSGI server or event framework being used
You are not bound to a specific event framework, when using
> you may just as well call a function directly on the WSGI server.
> Adding that function under a key in the WSGI environment and accessing
> it that way does not in itself provide any value and doesn't somehow
> make the code easily portable to a different WSGI hosting mechanism
> using a different event loop as you still have to change lots of other
> code in your application.
This is absolutely not true!
> In some respects this is similar to the issues between using a WSGI
> wrapper which injects stuff in WSGI environment versus that
> functionality being in a separate library. Read:
This is simply wrong.
x-wsgiorg.suspend **can not** be implemented as simply library code; it
**must** be accessed from environ dictionary.
The reason is simple:
1) First of all, in order to suspend application, you **must** return
control to the server, and this can only be done by yielding some
value in the application generator.
2) In order for the implementation to know if application requested
suspension, it must keep a flag in its *internal* state.
The x-wsgiorg.suspend function simply sets this flag.
More information about the Web-SIG