I am starting to look at your WSGI port of Webware, and I am hoping you
can give me some idea of where to start. What do I need to do to run
it? Are you using it with Apache or with a stand-alone web server? I
see there are some example files like Hello.py. How can I run those
and see that it works?
On Oct 3, 2004, at 12:18 AM, Ian Bicking wrote:
> I've made quite a bit of progress with the WSGI port of Webware,
> running two real applications I've written under it, without any
> significant changes to the applications (except for an import
> statement or two). The applications weren't written with WSGI in mind,
> so they didn't limit themselves to things that seemed simple under
> WSGI. OTOH, I wrote both of them, and I only use a subset of the
> Webware API.
> The Webware portion of this remains fairly minimal, mostly some simple
> classes that translate the WSGI environment and general system to the
> Webware API.
> In the process, I've made some reusable middleware that is
> Webware-neutral, but implements some of Webware's functionality (and I
> layer them in roughly this order):
> * httpexceptions; catches particular exceptions and turns them into
> HTTP responses (e.g., HTTPMovedPermanently, HTTPNotFound, etc). In a
> way I wish this was standard. However, the other middleware doesn't
> use this (though some of my Webware code does).
> * recursive; allows applications to forward to other URLs and to make
> recursive calls to include other URLs. These URLs have to be under
> the location where recursive is used.
> * session; implements sessions. The persistence is simple and doesn't
> take concurrency into account (yet), but the basic structure seems
> correct to me.
> * urlparser; this takes a URL and finds an application based on it.
> Currently it looks in a single directory, parses out the next part,
> and finds the application associated. Subdirectories turn into other
> urlparser instances. Finds .py modules, and looks for "application"
> (which is a ready-made application), or module.module_name, where the
> object must be called before it is ready to act as an application (in
> Webware's case, this is a class, instances of which are WSGI
> applications). Also serves up static files, like .css, .html, etc.
> * wsgilib; a number of generic functions for use with WSGI. Right now
> this includes:
> * Cookie parser: get_cookies
> * Something to add a finalizing function to an iterator: add_close
> * A way to run a request in a fake environment, for interactive
> debugging and testing: interactive
> * An error response creator (for 404 messages, etc): error_response
> * An application-builder for on-disk files: send_file
> I still need to do more testing, and write some unit tests for these
> middleware. But progress has gone well, and implementing a real-world
> framework on WSGI seems very doable. This is a more aggressive use of
> WSGI than many framework ports may make; a simpler porting technique
> would be to take the whole framework and find a single entry point,
> letting the framework keep all its URL parsing and other code. I'm
> doing this refactoring in part because I think it's the right
> direction for Webware, moreso than it's the best or easiest way to
> port a framework.
> Comments and suggestions welcome. The code is located at
> Ian Bicking / ianb@... / http://blog.ianbicking.org
> This SF.net email is sponsored by: IT Product Guide on
> Use IT products in your business? Tell us what you think of them. Give
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> Webware-discuss mailing list