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, and
ZPTKit.
-
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
applications.
-
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.
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 :-)
Sir Ian, 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."