I spent some time and got a good start on implemented Webware (the WebKit portion) for WSGI. It's missing a number of things, but it works for a basic servlet.
I'm excited about this, because I've been feeling frustrated with Webware for the last year or two. I felt like enhancements weren't really helping -- no one would use them, and I was only making it harder to do gradual Webware development. At the same time, the whole thing felt way too coupled, and it was hard to test or feel confident about changes.
I had considered various ways to improve Webware more incrementally, with an eye to decoupling. Standalone WebKit (in CVS) was one idea. It broke off a big chunk of Webware (WebKit), and cleaned up some portions (mostly configuration and installation). But there was a lot left. I could redo the entire thing, but I wasn't so in love with the Webware interfaces that I'd want to reimplement something that was entirely compatible. Yet backward compatibility (at least without major application modifications) was important to me.
Enter WSGI. I wrote before about a WSGI stack that would break WebKit into smaller, reusable chunks. Mostly by fidding with Transaction, HTTPRequest, and HTTPResponse I can get Webware working, with a small addition to Servlet as well. It's in svn://colorstudy.com/trunk/WSGI/ in WSGIWebKit (also viewable via viewcvs, but that can be flaky; install Subversion!) It ended up being easier than I expected. The servlets themselves become WSGI applications, which is cool; I can imagine WebKit servlets living side-by-side with a Quixote script, Spyce pages, etc. Not just peacefully coexisting, but as complete peers.
There's still probably quite a few bits of the WebKit API (informal though it is) that I'm missing, and some larger features (like sessions and a persistent, threaded appserver). I'm hoping to handle some of these features in a layered way, maybe using other people's work instead of implementing it myself. I feel optimistic about reusing code across projects.
It would be great if someone had a significant Webware application that also had good functional/system/acceptance tests; it would be a way to flesh out much of the API, and could provide a migration model (complete, seamless backward compatibility isn't my initial goal). Anyone? (No, I'm afraid I've never done complete automated system tests on any of my applications.)
In other WSGI news, the spec seems close to 1.0. I think Phillip wants to write some reference code as part of the spec, and there's still some asynchronous issues that haven't been resolved.
That's a good news. I've read the WSGI draft and perceive this as a next major step in maturing of Pythonic web platform. I was also a bit frustrated with WebKit as I feel "this could be done cleaner". While I doubt I could made any significant contribution to your efforts I wish you a good luck!
Personally, for my latest project, I abstracted the portion of WebKit's API I actually use into a facade class to decouple application code as much from WebKit as possible.
Ian,
You seem to have some url problems eg http://blog.colorstudy.com/ianIan%20Bicking/weblog/2004/09/29.html gives a 404.
Anyway this is good news.
Sorry Ian, the autodiscovery links are out too, e.g.
http://blog.colorstudy.com/ianIan Bicking/weblog/rss.xml
How annoying, the blog just spontaneously broke on me. My PyCS installation scares me, too...# Ian Bicking
While browsing the SVN, i really understand how WSGI can be used with the Webware API. But i'm wondering how to do the same w/ mod_python + apache
Someone has a URL ?
Bye Bye# Jkx
mod_python should be a fairly easy server to implement. WSGI would probably be a handler, similar to the publisher handler. Code written for mod_python is another matter. I don't think there's any way to support that, because you'd essentially have to recreate an apache-like environment without using Apache. Hopefully anyone who has programmed directly to the mod_python API realizes they have eschewed any portability; though many frameworks built on top of mod_python could be ported to WSGI, since most of those don't really use many mod_python-specific features.# Ian Bicking