http://cvs.sourceforge.net/viewcvs.py/webware-sandbox/Sandbox/ ianbicking/WebKit/
(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 [EMAIL PROTECTED] 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:
+++++++++++++++++ Standalone WebKit +++++++++++++++++
Ian Bicking <[EMAIL PROTECTED]> 3 Nov 2003
.. contents::
Goals =====
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...
Webware Package ---------------
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.
AppServer Startup -----------------
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.
Application Structure ---------------------
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.
File Locations --------------
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 Files -------------------
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`).
Hierarchical/Contextual Configuration -------------------------------------
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).
Logging -------
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.
Tabs ----
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 time.
And I hate tabs. I won't hide my personal bias here.
Status ======
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 this!)
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.
Usage =====
Edit ``FileLocations.ini`` to fit your environment.
Try::
$ cd WebKit/test/root
$ ../../Server
WebKit AppServer
....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...
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
