Winston Wolff wrote:
I've been thinking about future directions for Webware and WSGIKit. What do you think about shifting Webware into a WSGI container, with WSGIKit as one possible containee? Advantages would be greater separation of concerns, and easier testing. Perhaps more flexibility if lots of WSGI clients become available.

That's definitely the idea behind WSGIKit.

Here are the responsiblities of Webware that I can come up with. The first five would be handled by the Webware container, and the last three would be handled by the WSGI "client" if that's the proper term.

• Interface with Apache or provide built-in web server

This is kind of the quintessential WSGI thing. Right now there are several pure HTTP servers, CGI servers, and FastCGI servers. FastCGI still drives me nuts when I try to configure it, and the only server is multi-process. So there needs to be a little something more.


• Decode URIs and choose the servlet to call

wsgikit.urlparse -- it's pretty similar to 0.8's parsing, without the contexts. Overloading or other manipulation is done by introducing other parsers. It's also where ServletFactory-like functionality comes in, and where PSPFactory could come into play.


• Contain broken pages so it doesn't break the rest of the site

That's just hard. Very useful, but hard.

• Produce error reports when pages break.

WSGIKit doesn't have this yet, but it's definitely on my list to do.

• Speed development by auto-reloading when source has changed.

I can't figure out how to fit this one in. It's important. Subway has some reloading code, though I know little about it. Auto-restart doesn't fit quite as well, as there's no standard way in WSGI to ask the server to restart. We could add extensions to do that, at least for select servers.


• Manage sessions

WSGIKit has a small, kind of lame session handler. It's really part of the above stack more than the "client" (the webkit-simulating portion).


• Build an HTTP response with headers, cookies, and so forth.

This is solidly part of the webkit portion of WSGIKit, along with parsing the request. But even then it's pretty small -- parsing the request is done mostly with the cgi module, and the response is pretty simple.


• Write HTML

This is WebKit.Page, which I was able to move over with little change.

--
Ian Bicking  /  [EMAIL PROTECTED]  / http://blog.ianbicking.org


------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss

Reply via email to