What is WSGIKit?
Note: WSGIKit has been renamed to Python Paste
I think there's some confusion about what WSGIKit is, and what I
intend for it to provide:
- WSGIKit isn't WSGI. "WSGIKit" is, rather, a poor name for a
project. It really needs a new name. Greg McClure suggested
Underware, which kind of amuses me, but probably is a bad choice.
- WSGIKit isn't a WSGI server. Still, it does include glue for
servers (just a couple now, but more in the future). It will
probably be distributed with some servers, just because that's more
expedient and gives people a better experience.
- WSGIKit includes several pieces of middleware, like an error catcher
and a session manager.
- WSGIKit includes a from-scratch reimplementation of the Webware
API, but that API is completely separated in a subpackage
(wsgikit.webkit) and while it has (so far) driven the specific
features, it isn't preferred in any way.
- I use Zope Page Templates in the tutorial, but that's even less
connected, just some code to integrate ZPT written for the old
Webware, that also works for WSGIKit Webware.
- I've included a script (app-setup) for setting up new
application instances. This creates files and directories, and can
provide custom commands as well. This uses "application template",
the first of which (webkit_zpt) is based on Webware, Component,
- It includes a script for starting up servers and the general WSGIKit
environment. This involves creating a stack of WSGI middleware,
some application loader, and loading the appropriate configuration.
- It includes configuration. Configuration currently is just done
with Python files. To a degree other formats could be supported,
though often that is more difficult in practice than theory. This
configuration is used by a variety of middleware as well as the
server. It is also used by app-setup and possibly other
components. I've already integrated SQLObject (through
sqlobject-admin) into this configuration.
- It includes a single URL parser at this point, that matches the
general algorithm of Webware URL parsing. This is also,
essentially, the application builder -- it loads modules and files,
looks for appropriate objects in those modules, and can do small
amounts of conversion to get them in an appropriate state. It
doesn't strictly "know" about Webware, but not-so-coincidentally it
works with the Webware model. I'd like to include other URL
parsers/application builders -- as few as possible, but as many as
necessary to support the full range of URL parsing we see in the
wild. The full range isn't actually that full -- the current parser
plus an object publisher or two (configurable to provide
backward-compatible parsing) should do.
- The basic architecture is similar -- I think -- to Java servlet
filters. Or CherryPy filters. Or other pipeline-like systems.
Still when possible code should be provided as libraries instead of
middleware (it's more predictable, easier to use), but that's not
always possible. By using generic middleware -- especially as we
add more configuration to the middleware -- we can introduce global
and interesting functionality to an application or a set of
- It includes a kind-of test framework, based on py.test. Kind of a
framework, because it's not very complicated, but I've found it
quite convenient -- WSGI makes it easy to test individual pieces in
isolation, and to create fake requests. So unit testing can occur
reliably on a fairly granular level. I've also been building a bit
of a framework for testing tutorials with doctest.
- Hopefully soon it will provide a nice installation experience,
including a large download that includes all sorts of optional
pieces that might be useful or helpful.
So... that's what WSGIKit is. I'd really like to support more
frameworks, more servers, and bring more developers in. There's room!
I'm willing to give commit access to anyone who's been around in the
community, or really anyone who shows a little interest and competence
(and of course plays well with others) -- the nice thing about version
control is that nothing is permanent, so we might as well take
advantage of that. I think WSGIKit has the potential to provide a
compelling and simple installation and configuration experience for a
whole variety of frameworks, removing the diversity that's not
interesting but just annoying. At the same time it shouldn't infringe
on any of the interesting diversity. It's also a good, testable,
decoupled architecture to make a solid foundation.
Update: A couple people complained that I haven't actually said what
WSGIKit is, maybe just where I think it should fit in. So...
- WSGIKit uses WSGI (PEP 333) as its means of internal communication. In practice, this is like a request and response object, in the form of the environ dictionary (the request) and the return values and callbacks (the response). The PEP explains WSGI well, so I won't repeat the whole thing.
- WSGIKit includes a "server" program, which starts up a server (e.g., Twisted)
and reads the configuration, and sets up the stack of components and middleware.
If you look at the tutorial, you'll see some of how that works (the tutorial doesn't
leave out any steps, except for the download-all-components part, which I'm still
working out). In many ways, I'm seeing that this startup process is fairl central.
- WSGIKit isn't a framework, but kind of a glue for frameworks, and infrastructure to
set up and deploy projects. It's like a metaframework, but maybe that makes it
sound fancier than it actually is.
- WSGIKit contains reusable components for use in frameworks. It's like a library
for frameworks, and a library for some stuff that wasn't possible to generalize
across frameworks without WSGI. From this perspective, it's only interesting to
framework authors (though web developers tend to drift into framework development
whether they want to or not, so it's not entirely hidden).
So... what is WSGIKit? Maybe I'm a little confused now as well. I guess it's really
about glue and reusable components to be provided to framework authors. Which puts it
in a slightly funny place, because as glue it's actually front-facing to users in many
ways. It's not an app server -- it can be run in a threaded, multiprocess, or CGI
environment, embedded in Twisted, Apache, or another container. It's not a framework,
those get built on top. It's not a template at all, nor any sort of model. It's
just a lot of glue, I guess.
Created 15 Apr '05
Modified 23 Apr '05
Bah! This does not explain what WSGIKit is. It explains various things that it contains, but not what it's for. There I was thinking "ahahaha! now I will suddenly get to see what the whole WSGI thing is all about, since I am clearly not in touch with the Zen because I don't get it", and...this has not made things a lot clearer :-)
Your Kung Foo is the greatest. But You still have not explained what WSGIKit is. Is it an app server? Where does it fit in the stack of Web server, templating engine, model and interface to the model?
A picture might be worth a thousand words here...
I think Mr. Sparks has it right here -- one rough graphic with some boxes and arrows could probably largely explain what you've clearly put a lot of time into writing. Perhaps a couple possible setups with well-known (in python webapp world at least) frameworks and/or behind apache with the parts labeled would probably explain it once and for all for the dim-witted or short of attention of us out here.
And if you happen to be on a Mac and/or have access to OmniGraffle that app makes almost any diagram look all fancy and special.
Also I keep sort of sensing the word 'substrate' as kind of what/where wsgikit is - maybe 'webstrate'. Assuming I kind of understand correctly...
Framework glue, huh? Pehaps you could call it "sticky" or "elmers", "Pyste" (python-paste or phonetically "pissed"). I'm envisioning frameworks as popsicle sticks or toothpicks and WSGIKit as the paste that holds it all together. Hmm... WSGIKit -> stikwig, swiktig, wisk, gitwisk, wig skit! Hmm... running "wsgi glue" through an gives "wiggles u". ;-) Hmm... What about "Waypoint"?
Just call it Chicago... as in "all roads lead to Chicago". ;-) Isn't that what WSGI is all about? For a more Euroasian reference, you could use "Constantinople", but that's pretty long. Besides, aren't you from the windy-city?
I'll add my voice to the general clamor of those who were hoping for an actual answer to the title question. I'm pretty sure now that it has more to do with web presentation than it does with scientific computing... but I was hoping to pin it down a bit more clearly. An example or two might help: "I would use WSGIKit when coding XXX because it provides YYY."