A while ago there was a thread on the webware-discuss mailing list that helped me think about what WSGIKit's role is in relation to Webware, and what my own goals are.

First, is WSGIKit purely a reimplementation of Webware, or is it an improvement on Webware? Really part of what I want from WSGI is the possibility to move beyond the Webware interface and API without splitting environments; which is why I want to have something that is backward compatible with Webware while leaving the possibility for using novel new techniques alongside it. I can imagine all sorts of better interfaces, but I don't want to break Webware trying to get there. Several years ago that might have made sense for Webware, but it doesn't make sense now, that's just not the place Webware is strategically.

And while I want to support Webware applications indefinitely, it might not be that long before I'm programming with something else. Achieving that incrementally is part of what I want to do with WSGIKit -- so that Webware melts away more than me just choosing (or making) Yet Another Framework. WSGIKit supports a thin Webware interface over a bunch of neutral components, which means choosing Webware at that point would be more of an aesthetic choice than a platform choice. Which a good choice to ask users to make. The way things are now, it's more about weighing the shortcomings rather than looking for the advantages.

Webware has particular attributes, like the AppServer, the exception handler, etc. These I think of as features, but not its essence. Another framework could reach parity with Webware fairly easy in those terms, but if it matches the Webware interface then it "is" Webware. In that way WSGIKit can be Webware.

You can build a better interface on top of Webware. It's reasonably easy, really -- Webware is lighter than it might seem, and you could wrap things in a quite different interface, create what would be an entirely new framework. The disapointing part is that such a sub-framework will appeal to only a portion of the Webware audience, which is a small portion of the Python audience. At each point you're splitting your audience into ever smaller chunks.

And so I realize that the biggest reason I'm interested in WSGI and WSGIKit is because I don't want to split my audience, I'm tired of that. I accept and am okay that my audience is people who are using Python, but if it's just people who use Python and have chosen Webware, that's too small a chunk. And I don't like the idea that first you choose your framework, then you choose the other libraries based on that; that's not a good way to make a choice.