dirtSimple.orgwhat stands in the way, becomes the way
WSGI Is Dead: Long Live WSGI Lite!

WSGI Is Dead: Long Live WSGI Lite!

Almost a decade ago, back when I first proposed the idea of WSGI to the Web-SIG, I had a rather idealistic vision of how WSGI could be a kind of “framework dissolver”.  I envisioned a future in which everything was pluggable, and there would no longer be any reason to have monolithic application frameworks, because everything could be done with libraries, middleware, and decorators.

Alas, that idealistic future didn’t come to pass.  In fact, as far back as 2007, I had already noticed it wasn’t working, and proposed an idea for a WSGI 2 protocol that would resolve the problems…  and then proceeded to do nothing for the next few years.  (Well, I’ve been doing other things, like working on setuptools, Chandler, and my own business.  I just wasn’t working on web apps or WSGI!)

Anyway, last week, Armin Ronacher wrote a great article on his blog called WSGI and the Pluggable Pipe Dream, about this very topic.  If you haven’t read it, I urge you to do so, as it provides in-depth coverage of many of WSGI’s dark corners and design decisions that are not widely understood by people who weren’t involved in the original design, or who haven’t spent a lot of time working with it.

But I was a little disappointed with the end of the article, because Armin’s build-up led me to believe he had a solution to the problems of dealing with crud like start_response, write, close, and all that in WSGI middleware.  But really, his claim ended up being that even if somebody invented something better than WSGI, there would be no way to replace it, because of all the investment in the existing protocol.

So, I decided to do something about that.


Introducing WSGI Lite, WSGI’s new younger brother.

WSGI Lite is a protocol that’s basically the same thing as the “WSGI 2” calling convention I proposed four years ago, and pretty much the same as what other languages’ versions of WSGI use.  There’s no start_response, close, write, or exc_info to mess with, and I even threw in a massively improved way to manage post-request resource release and cleanup operations.

Now, if WSGI Lite were just a WSGI alternative, Armin’s article would be right: nobody would use it, because it’d be in competition with WSGI, and we’d have to basically “Shut…  Down…  Everything”  in order to replace it.

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.

Which means, you don’t have to replace anything; you can just start using it, wherever it’s appropriate or useful to do so.

All it takes, is two decorators: one to declare an app as being a “lite” app, and one to allow you to call standard WSGI apps using the “lite” calling protocol.  (And, as a special bonus, the decorator you use for new code can also automatically bind environment keys, session/request objects, or other cool things to your app or middleware’s keyword arguments.  It’s tres chic.)

I’m hoping that this will revitalize the “pluggable pipe dream”, and make it a little less dream, a little more pipe.

So try it out, and let me know what you think.

Update: on reflection, the above article is woefully inadequate to explain the actual rationale of the WSGI Lite protocol or its implementation, so I’ve written a follow-up piece to cover that.  Check it out!

Join the discussion
  • Found Armin Ronacher's rant grossly delusional.

    The WSGI.Input issue that he alludes to is fixed in PEP3333. Chunked handling is fixed along with it.

    The rest of his complains is centered about complexity. What complexity? Don't want to craft generators, return array with one string…

    CherryPy, ModWSGI already have production-level code out with support for PEP3333 on both, python 2.x and 3.x.

    The post is just lota hot air. For what? So you would be compelled to roll "simplification middlewere" overnight to show how simple it it to make writing simple WSGI apps in a more complex way?

  • Please make port this to Py3k. The reason being is that Py3k is starting to be used for new works. New works are the most likely place that wsgi-lite would be adopted IMHO. Make sense? Good.

  • The pipe link repeats the same HTML address twice. Copy to the address bar and delete one to see crude hand-drawn "pipe", and perhaps the author will fix this soon.



Stay In Touch

Follow our feeds or subscribe to get new articles by email on these topics:

  • RSS
  • RSS
  • RSS


Get Unstuck, FAST

Cover photo of "A Minute To Unlimit You" by PJ Eby
Skip to toolbar