[Webware-discuss] WSGI Webware

[Ian B. <ia...@co...>]

I just committed some code to my repository (at 
svn://colorstudy.com/trunk/WSGI/) that implements WebKit ontop of WSGI. 
   If you haven't heard of WSGI, it's PEP 333: 
http://www.python.org/peps/pep-0333.html

It's not complete, but much of the core is there.  There's no 
configuration, no AppServer or Application object, no session, and the 
path (URL introspection) methods are missing.  The path methods in 
Webware are a mess, which is part of why I left them out.

AppServer and Application objects don't really apply in a WSGI context. 
  I hope to create dummy objects for those few places where they are 
exposed.  Configuration probably will be implemented in a different 
layer, and all the configuration will change, since it's a different 
environment you are configuring.  Sessions will probably be in a 
different layer as well, maybe with a wrapper to implement the WebKit 
interface around a session that may not have that interface.  The path 
methods will just wait.  They also don't map well, because with no 
AppServer or contexts, and pluggable URL dispatching, many of the 
methods don't make sense anymore.

Also, there's no URL resolution.  I'm just using dispatch.py for now, 
which is a WSGI middleware that implements naive way of selecting WSGI 
applications.  But I plan to keep dispatching in a separate layer -- 
this way different frameworks can live side-by-side.

Instances of WSGI.WSGIWebKit.wkservlet.Page are WSGI applications; 
basically the new method Page.__call__ does the work.  Most of the rest 
of the code is copied from WebKit with some cleanup; there's some small 
portions that were changed, like HTTPResponse.__init__, write, commit, 
and deliver, and HTTPRequest.__init__.

Right now the only WSGI server I've used it with is CGI-based, which is 
equivalent to OneShot; I'm hoping to use someone else's threaded server 
later (maybe based on Medusa or Twisted).

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org