Well, I tried to explain WSGIKit, but I'm not entirely sure how successful that was. People asked for diagrams, but I don't think in terms of diagrams (even if I appreciate that it's very useful for other people), so I'm not sure what one would look like. I made a couple diagrams for my WSGIKit PyCon presentation, which may or may not help.

But anyway, I want to write about what WSGIKit can do for you, the framework developer. To do this, I want to explain Webware's relation to WSGIKit, which is a concrete example of how this stuff can fit together.

• Webware has a package (wsgikit.webkit) that implements the Webware API. It's included with WSGIKit because it's a reimplementation of Webware. If you didn't want to reimplement your framework, or you wanted to do all your framework development in your repository, you wouldn't necessarily add a subpackage, you'd just use your normal distribution.

• The Webware package turns Servlets into WSGI applications. While this effects a whole bunch of stuff, in a lot of ways it's actually pretty simple. If you look at wsgikit.webkit.wkservlet.Servlet, the core WSGI application logic is in __call__ (though, I suppose, spread out over Response and Transaction as well).

  This may or may not be feasible for other projects. Servlet happened to not be using __call__, so I could add that method. wsgikit.urlparser.URLParser uses some simple rules to construct WSGI applications -- it loads modules, then looks for the symbol application, which is a ready-made WSGI application, or a symbol matching the module name, which is a factory for WSGI applications. The Webware Servlet subclass is a factory for Servlet instances, which are themselves WSGI applications.

  Some frameworks would be able to use this, or maybe offer modifications of this, while other frameworks will have to implement new URL parsers.

• So far just one application template is included, wsgikit/app_templates/webkit_zpt. This is used by app_setup to create a blank application file layout (the tutorial makes use of this). Frameworks can have multiple templates (e.g., someone could write a webkit_cheetah template), and the application templates can provide new commands. So sometime I'm planning to add a app-setup servlet <servlet_name> command to webkit_zpt that will create a new blank servlet and template. None of the application template stuff is required, but I think it's a very helpful aid to new users (and convenient for experienced users too).

• There's a function in wsgikit.server that when it sees a webkit_dir configuration value, loads up the wsgikit.webkit.wsgwebkit.webkit() stack of middleware, that provides all the functions Webware provides. I want to make this kind of configuration and application assembly pluggable, but for now it'd probably mean hardcoding something for each framework in there. Actually, I plan to rename webkit_dir to something like publish_dir, as there's nothing Webware-specific about it, just file-publishing-specific. But I'm very reluctant to turn configuration into something complicated, so right now I'm expecting to code many use cases into server instead of making configuration more generic or general.

OK, so if you set up your framework to work with WSGIKit, what would you get out of it?

• You get app-setup if you make application templates. You can make such a thing on your own (Webware had MakeAppWorkDir for instance). But this script provides a somewhat consistent experience for users, and convenience functions (e.g., app-setup --template=webkit_zpt is implemented like this). app-setup list will show your framework, for a little free advertising.
• You get a configuration setup. It's fairly simple -- and maybe it can stay fairly simple. The same configuration file works for both servers and applications, and can hold information specific to your framework or applications.
• You get glue for various servers. There's a couple supported now, including a simple HTTP server, a print-to-stdout server, a CGI-script-generating server, and an SCGI forking server. There will be more in the future.
• Servers can be restarted automatically when code changes (configurable), dealing with the dreaded stale code problem.
• Access to a bunch of reusable components and libraries, like serving of static files, catching errors and providing a variety of reports, session management, authentication, and more to come.
• Less code in your framework.
• As much backward compatibility as we can muster. Deployment and configuration changes, but most everything else shouldn't.

I also think the test and documentation framework is heading in a good direction.

You don't have to use all of this to pick features and code out of WSGIKit if you wish. A lot of what I'm looking to provide with WSGIKit is a good experience for users, both new and experienced, and part of what that means is having other people put things together in intelligent ways instead of leaving it up to each developer to do so. Wouldn't it be great to tell someone evaluating Python web programming to download one (maybe big) hunk of code, run app-setup list to see a dozen available Python frameworks, app-setup list -v to get extended descriptions, app-setup --template=X create ~/test_X; cd ~/test_X; wsgi-server to get a demo of any of the frameworks set up? That's not the end-all-be-all of resolving issues with Python web development, but I think it's an accessible goal right now, and worth doing.