[Web-SIG] [ANN] twsgi: asynchronous WSGI implementation for Twisted Web

[Graham Dumpleton]

On 9 April 2010 21:29, Manlio Perillo <manlio_perillo at libero.it> wrote:
> Graham Dumpleton ha scritto:
>> [...]
>>>    - the name will be 'wsgiorg.suspend' instead of 'wsgi.pause_output'
>>>
>>>      The wsgiorg namespace is used, since the plan is to have it
>>>      standardized [1], but it can only be implemented on asynchronous
>>>      servers.
>>
>> Please read:
>>
>>   http://www.wsgi.org/wsgi/Specifications
>>
>> If a proposal is suggested, it MUST use 'x-wsgiorg.' and not
>> 'wsgiorg.'. Only after it is officially accepted can it use the
>> 'wsgiorg.'.
>>
>
> Well; since the original propose was using wsgi namespace, I just
> suggested the use of wsgiorg namespace instead
>
> Of course, when it will be implemented I will use a different namespace,
> until it gots approved.
>
>> I would question whether you should even be using 'x-wsgiorg.' as as
>> far as I can see from my quick scans of emails, you aren't even
>> supporting WSGI proper as you are dropping support for bits. As such,
>> it isn't WSGI, only WSGIish so how can you justify using the name.
>>
>
> This is not completely correct.
> The twsgi implementation, as well ngx_http_wsgi_module implementation,
> does not implement the write callable.

So, they aren't compliant with WSGI specification. How is my statement
not correct? If not compliant, how can you use WSGI in their names?

> The reason is simple: write callable was an huge mistake in WSGI 1.0
> since it can not be implemented in an asynchronous web server.

It may not be the preferred way of doing things now, but it was not a
huge mistake. There was a lot of stuff back then that used a write()
style semantic for returning response content and that was the only
way of supporting them without forcing those packages to do a major
rewrite to change to an iterable type response. So, it served its
purpose.

> But since the write callable **can** be implemented in a middleware
> (using greenlets) and since middlewares *can* be configured inside WSGI
> gateway, implementations can still claim to be WSGI 1.0 conformant.

Then only the higher level middleware adapter can even claim to be
WSGI compliant and deserve to use the WSGI name. Any underlying
abstraction you use at the web server interface isn't WSGI and by
rights should be called something else so there is no confusion and
also shouldn't use 'wsgi' keys in its environ dictionary. Have your
high level middleware do a completely remapping of names as
appropriate.

>> Why don't you given it all a completely different name else you will
>> just cause ongoing confusion
>
> In don't really see how this can cause confusion!

So, when someone goes and runs a WSGI application directly against you
WSGIish web server interface which you still insist you can describe
as being WSGI and it fails because the write() method isn't
implemented what is your answr going to be? If something is going to
use WSGI name it should implement the full WSGI specification.

>> like you did with when you felt you could
>> reuse the 'mod_wsgi' name for your nginx
>
> In fact the first thing I did during code refactoring was to rename it
> to ngx_http_wsgi_module.

The mod_wsgi name is still used all through
http://wiki.nginx.org/NginxNgxWSGIModule that I can tell.

Graham