
WSGI Is Dead: Long Live WSGI Lite - jp_sc
http://dirtsimple.org/2011/07/wsgi-is-dead-long-live-wsgi-lite.html
======
j_baker
_But the WSGI Lite protocol is actually backwards compatible with WSGI. You
can write code to the WSGI Lite API, and transparently interoperate with
existing WSGI servers, apps, and middleware._

Correct me if I'm wrong, but doesn't this mean that it's WSGI _extra_ rather
than WSGI _lite_? I mean, you don't generally consider the lite version of
something to have the all the features of the full version and then some.

~~~
philipn
I think it just adds the boilerplate back in there for you :)

~~~
j_baker
...so then it's a framework?

~~~
pyninja
Are you serious?

------
inarru
is it just me or is this completely flawed as a response to armin's article?

\- Armin: "you can't replace the 'bad' bits of WSGI for asynchronous apps
without using some python extension like greenlet"

\- to which this article replies: "Armin is wrong, i've replaced WSGI! PS _:
if you're an asynchronous server you have to use greenlet!"

_ see 'known limitations'

basically, in trying to challenge armin he's proved him right. and he does
this without a hint of irony?!

~~~
pyninja
No, that's not what he's saying... and I don't know if you realize this, but
the author, P.J. Eby, is the same guy who wrote the original WSGI spec.

~~~
inarru
> I don't know if you realize this, but the author, P.J. Eby, is the same guy
> who wrote the original WSGI spec.

yup (though to conclude anything from that fact is a clear fallacy).

I've realised that what I actually disliked most was his blog-post and not the
actual project (I've used identical shims to wsgi-lite by choice over the
years).

"CAN'T REPLACE WSGI WITH SOMETHING BETTER? CHALLENGE ACCEPTED"

"WSGI IS DEAD" (Except when it isn't.)

I realise that the above was probably done for facetious editorial reasons
rather than his actual intention with the lib. He hasn't really replaced wsgi,
he admits should only be used _wherever appropriate_

Armin uses the async point in part to give technical reasons why WSGI can't
really be replaced in full, before concluding that he thinks replacing WSGI
for purported notions of pluggable utopia is a red-herring anyway before
posing the question of any WSGI replacement: does this really '[make]
frameworks work better with each other?'

I don't think PJ really tackles any of that.

------
po
This actually seems like a reasonable approach to me. WSGI isn't really
friendly to application developers (because it's not the API they expect when
they naively approach the problem) so mostly it's been wrapped by the various
frameworks. Armin's article seemed to be saying "Stop bitching that you can't
use WSGI because it's more complex than you think. Here's why. Just pick a
framework."

This approach seems to take care of the 90% problem while leaving the full
power of WSGI exposed if you want/need it. It's like a minimalist web
framework to do just the smoothing over of the WSGI API and nothing else.

The backwards compatability is key: It can be adopted by application
developers, and doesn't depend on server developers.

It may not have sprung into existence in a perfect form but I think it is
definitely worth exploring this approach.

------
draegtun
Some related blog posts:

* _Let's talk about WSGI_ \- <http://www.b-list.org/weblog/2009/aug/10/wsgi/>

* _Snakes on the web_ \- <http://jacobian.org/writing/snakes-on-the-web/>

------
bitanarch
Ok, I'm using WSGI every day but I haven't delved down into the details of it.
But what would be the benefits of using WSGI Lite instead of the regular WSGI?
Performance?

~~~
inarru
the _only_ benefit is not using start_response() before returning your data.

~~~
inarru
well, that's not quite all. _if you're writing middleware_ you sometimes have
to write a some (mostly reusable) extra code to pass as the start_response()
to other wsgi callables. (to access the headers and/or munge anything sent by
.write() -- or disallow .write() entirely).

------
lenni
I always thought of WSGI as a bridge between the web server and whatever web
framework you happen to use, but this and the referenced article talk a lot
about interaction between different frameworks and applications.

I don't really understand what is meant by this. Does this mean they want
Django to interact with, say, Bottle?

