I've added a project to the Webware Sandbox
(http://webware-sandbox.sf.net), a refactoring of Webware to separate
out WebKit and generally make it easier to install, configure, and
administer. It's in Sandbox/ianbicking/WebKit, viewable through the
(Anon CVS on SF can be a little delayed -- anyone interested in this or
any other project in the sandbox can get their own account, just email
webware-devel@... and include your SourceForge username; if
there's interest, I can also set up snapshots of CVS HEAD)
I'll simply copy the README as an introduction:
Ian Bicking <ianb@...> 3 Nov 2003
The goal of Standalone WebKit is to make Webware installations easier
to manage and distribute, and generally make Webware (WebKit) more of
an environment and library, and less of an application.
Standalone WebKit tries not to fix or enhance other things -- I've
tried to keep its scope of changes fairly reasonable.
What, Oh What Have You Done?
Some particular changes have been made...
The `Webware` package has been eliminated. `PSP`, `TaskKit`,
`MiscUtils`, and `WebUtils` have been moved into `WebKit`.
`MiddleKit` is intended to be distributed separately -- it's probably
already close to being distutil-ifiable, and it's a general-purpose
ORM without special ties to Webware (or vice versa). `CGIWrapper` and
`UserKit` have been deprecated.
`WebKit` can thus be installed with distutils. I haven't written the
``setup.py`` file for this, but it should be easy enough.
The new startup script is called `Server`. This includes a CGI form
of the Server which replaces OneShot. Hopefully it can be made to run
a bit faster than OneShot. I'd like to write a `ModPythonServer` at
some point, which will run the application server inside of
mod_python_ (entirely unlike `ModPythonAdapter`, which only uses
mod_python to connect to the threaded persistent application server).
.. _mod_python: http://modpython.org
HTTP server is also a little easier to enable, and more of a peer with
the adapter interface.
Web applications are simply kept in a directory. No
``MakeAppWorkDir.py`` is required. You run `Server` inside the
directory. It automatically picks up any ``webware.ini`` file it
finds to add configuration, and starts serving those documents from
the root. `URLParser` ``__init__.py`` hooks exist to allow other ways
of combining directories and resources in the URL space (eventually
these should be made available through the configuration).
It should be reasonably easy to nest applications inside each other
this way, like nesting ``Admin`` inside your root application.
Multiple servers are easy to run this way as well.
Files can (but are not required to) be strewn all over the place. In
particular, in typical Unix filesystem paths, like
``/var/run/webware.pid`` and ``/var/log/webware``. An additional
level is also included, so it's actually
``/var/run/webware/port_8086.pid``, to support running multiple
Webware installations simultaneously.
The goal is that Webware be a good server/daemon citizen. The WebKit
directory should be entirely self-contained.
Configuration is no longer kept in Python-syntax files. Well, it can
be, but doesn't have to be -- defaults are still kept in such a file,
because it is fast to parse. ``FileLocations.ini`` gives a basic
sense of what a configuration file can look like. I used the INI file
parser included with Python just out of convenience -- a better
configuration syntax is probably called for. Hooks exist to support
multiple syntaxes, with each having its own extension.
Configuration is handled more globally, instead of with mix-ins. The
`Configuration` module holds the typical class, and `Common` contains a
instance of `Configuration` called `GlobalConf` and `WebKitConf`.
Separate configuration contexts are still supported (`WebKitConf` is a
configuration section of `GlobalConf`).
Configuration can also be updated by ``webware.ini`` files found in
your path. As you traverse the URL, these configuration files are
picked up automatically, but apply only to that transaction. Settings
like whether to email errors can be locally configured. This should
make application plug-ins a bit easier too, as you can configure them
hierarchically (for instance, to configure specific authentication
hooks, or what-have-you).
While quite incomplete, I've tried to replace Webware's use of
``print`` with calls to the logging_ module. This makes ``if debug:
print ...`` statements unnecessary (you just set the logging level to
show or hide log messages on that level), and should also provide good
application-level hooks for logging.
.. _logging: http://www.python.org/doc/current/lib/module-logging.html
In addition to not having removed all the ``print`` statements, I also
haven't defined a set of hierarchical loggers, which would be
advantageous, or exposed many configuration values related to logging.
I removed all tabs, replacing them with 4 spaces. I couldn't help
myself. They never grew on me. They haven't grown on the larger
Python community either -- tabs become consistently less popular over
And I hate tabs. I won't hide my personal bias here.
It's pretty crude, I'm afraid. A lot of work has been done, and you
can start it up and run applications. The fundamentals are there.
But a lot of the previous stuff has been broken in the process, and I
haven't fixed it all yet. Every file has been touched, so there's
issues to be dealt with all over the place.
No documentation exists. In light of all the changes, all the old
Webware documentation has to be reviewed for accuracy. (And a lot of
it can be deleted, because some stuff has been simplified by all
Tests *need* to be written. This is my next step, I'm not going to
try to fix anything more until I write tests. That's my promise to
myself more than anything, a test of will ;)
Backward compatibility should be kept, when possible. This shouldn't
be too bad -- mostly stuff that depends on contexts (even trivially)
will break now. Empty strings and other null values need to be
returned for some of the context-related methods. Anything else that
breaks applications too badly needs to be fixed too, though I expect
applications to require at least a little modification before they
work (and causing exceptions in applications is better than causing
silent bugs in those applications).
The whole thing needs to be distutil-ified. That's not too hard at
this point, but a bit more directory structure needs to be built up.
Edit ``FileLocations.ini`` to fit your environment.
$ cd WebKit/test/root
You'll see less messages than you did before. Or try::
$ ../../Server --EnableHTTP=yes --HTTPPort=8080
Then you'll be able to browse directly on port 8080.
There's so much more to document, though...