Note: WSGIKit has been renamed to Python Paste

I think there's some confusion about what WSGIKit is, and what I intend for it to provide:

• WSGIKit isn't WSGI. "WSGIKit" is, rather, a poor name for a project. It really needs a new name. Greg McClure suggested Underware, which kind of amuses me, but probably is a bad choice.
• WSGIKit isn't a WSGI server. Still, it does include glue for servers (just a couple now, but more in the future). It will probably be distributed with some servers, just because that's more expedient and gives people a better experience.
• WSGIKit includes several pieces of middleware, like an error catcher and a session manager.
• WSGIKit includes a from-scratch reimplementation of the Webware API, but that API is completely separated in a subpackage (wsgikit.webkit) and while it has (so far) driven the specific features, it isn't preferred in any way.
• I use Zope Page Templates in the tutorial, but that's even less connected, just some code to integrate ZPT written for the old Webware, that also works for WSGIKit Webware.
• I've included a script (app-setup) for setting up new application instances. This creates files and directories, and can provide custom commands as well. This uses "application template", the first of which (webkit_zpt) is based on Webware, Component, and ZPTKit.
• It includes a script for starting up servers and the general WSGIKit environment. This involves creating a stack of WSGI middleware, some application loader, and loading the appropriate configuration.
• It includes configuration. Configuration currently is just done with Python files. To a degree other formats could be supported, though often that is more difficult in practice than theory. This configuration is used by a variety of middleware as well as the server. It is also used by app-setup and possibly other components. I've already integrated SQLObject (through sqlobject-admin) into this configuration.
• It includes a single URL parser at this point, that matches the general algorithm of Webware URL parsing. This is also, essentially, the application builder -- it loads modules and files, looks for appropriate objects in those modules, and can do small amounts of conversion to get them in an appropriate state. It doesn't strictly "know" about Webware, but not-so-coincidentally it works with the Webware model. I'd like to include other URL parsers/application builders -- as few as possible, but as many as necessary to support the full range of URL parsing we see in the wild. The full range isn't actually that full -- the current parser plus an object publisher or two (configurable to provide backward-compatible parsing) should do.
• The basic architecture is similar -- I think -- to Java servlet filters. Or CherryPy filters. Or other pipeline-like systems. Still when possible code should be provided as libraries instead of middleware (it's more predictable, easier to use), but that's not always possible. By using generic middleware -- especially as we add more configuration to the middleware -- we can introduce global and interesting functionality to an application or a set of applications.
• It includes a kind-of test framework, based on py.test. Kind of a framework, because it's not very complicated, but I've found it quite convenient -- WSGI makes it easy to test individual pieces in isolation, and to create fake requests. So unit testing can occur reliably on a fairly granular level. I've also been building a bit of a framework for testing tutorials with doctest.
• Hopefully soon it will provide a nice installation experience, including a large download that includes all sorts of optional pieces that might be useful or helpful.

So... that's what WSGIKit is. I'd really like to support more frameworks, more servers, and bring more developers in. There's room! I'm willing to give commit access to anyone who's been around in the community, or really anyone who shows a little interest and competence (and of course plays well with others) -- the nice thing about version control is that nothing is permanent, so we might as well take advantage of that. I think WSGIKit has the potential to provide a compelling and simple installation and configuration experience for a whole variety of frameworks, removing the diversity that's not interesting but just annoying. At the same time it shouldn't infringe on any of the interesting diversity. It's also a good, testable, decoupled architecture to make a solid foundation.

Update: A couple people complained that I haven't actually said what WSGIKit is, maybe just where I think it should fit in. So...

• WSGIKit uses WSGI (PEP 333) as its means of internal communication. In practice, this is like a request and response object, in the form of the environ dictionary (the request) and the return values and callbacks (the response). The PEP explains WSGI well, so I won't repeat the whole thing.
• WSGIKit includes a "server" program, which starts up a server (e.g., Twisted) and reads the configuration, and sets up the stack of components and middleware. If you look at the tutorial, you'll see some of how that works (the tutorial doesn't leave out any steps, except for the download-all-components part, which I'm still working out). In many ways, I'm seeing that this startup process is fairl central.
• WSGIKit isn't a framework, but kind of a glue for frameworks, and infrastructure to set up and deploy projects. It's like a metaframework, but maybe that makes it sound fancier than it actually is.
• WSGIKit contains reusable components for use in frameworks. It's like a library for frameworks, and a library for some stuff that wasn't possible to generalize across frameworks without WSGI. From this perspective, it's only interesting to framework authors (though web developers tend to drift into framework development whether they want to or not, so it's not entirely hidden).

So... what is WSGIKit? Maybe I'm a little confused now as well. I guess it's really about glue and reusable components to be provided to framework authors. Which puts it in a slightly funny place, because as glue it's actually front-facing to users in many ways. It's not an app server -- it can be run in a threaded, multiprocess, or CGI environment, embedded in Twisted, Apache, or another container. It's not a framework, those get built on top. It's not a template at all, nor any sort of model. It's just a lot of glue, I guess.