QP is a package for defining and running multiple web applications based on Durus for persistence, standard persistent Session and User classes, easy interactive database sessions, qpy for assembling html, and forms and path traversal. QP makes it easier than ever to use these tools together.
QP includes a http/scgi server that dispatches requests to a pool of long-running single-threaded worker processes. With QP your applications can
QP includes a site-management capability.
One command line utility (named "qp") is used for
controlling all of the servers for multiple sites.
Run qp --help to see the options available for the qp command.
To define a new site named, for example, hello, start with a copy
of the proto site:
cp -r /www/trunk/DurusWorks/proto /www/trunk/hello
ln -s /www/trunk/hello/lib /www/pythonlib/hello
ln -s /www/trunk/hello/site /www/qp_sites/hello
Edit /www/trunk/hello/lib/ui/slash.qpy to
configure the service addresses.
Edit your apache configuration to provide virtual
hosts that connect to the correct port for the SCGI server.
Edit /www/trunk/hello/site/slash.py and change the
import to this:
from hello.ui.slash import SitePublisher, SiteDirectory
Use the qp command to check that the hello
site runs. Now you can add your customizations to /www/trunk/hello/lib and use the qp command
to stop and start the site as needed to check your changes.
The customization options and in particular, the usage of the SiteDirectory, SitePublisher, and Form classes are beyond the scope of this document. To learn more, please study the proto demo and the QP source code.
The SitePublisher class should be a subclass of qp.pub.publish.Publisher,
with a configuration class attribute identifying addresses for the
servers you want to run.
Note that python will find your site packages as a subpackages of qp.sites,
so the slash module of a site named hello, for example, can be imported
in python as qp.sites.hello.slash.
The SiteDirectory class should be a subclass of qp.fill.directory.Directory
that defines your site's content.
Here we will summarize the roles of some of the modules in the QP package.
Form class, which provides a framework for
rendering HTML forms and dealing with submitted forms.
Widget classes for use by the Form class.
There are different widgets for different kinds of form inputs.
Directory.
We use instances of this class to define the URL space of every application.
Every QP site must define a SiteDirectory class that is a subclass of
Directory. The SiteDirectory class defines the entry
point for traversing the URL path.
DurusDirectory, a very specialized subclass of
Directory used for browsing directly into a Durus database. This is
useful for learning about the database structure.
StaticFile and StaticDirectory,
which allow applications to deliver static content.
HTTPRequest class.
HTTPResponse class.
Keep
class that makes it easy to get this job done.
Profile, a class that can be used
to test the QP request/response machinery directly, without involving
any HTTP transmissions.
Site, the class that provides the API that
QP uses for managing multiple sites.
specs, which are
callables that are used to verify an argument's type or other qualities.
We use the spec pattern to declare and verify the attributes
of nearly all instances in the database.
sendmail() function and an Email
class that can be used for constructing and sending email.
SitePublisher and other instances
it references.
Hit class. An instance of Hit has references
to the current HTTPRequest and HTTPResponse instances.
Publisher base class is defined in this module. Every QP site
must define a SitePublisher class that is a subclass of Publisher.
Session class is defined here.
User class. It also include the
Digester, used behind the scenes to maintain information needed
for authenticating users. The TokenSet is used by User
to provide a way to prevent forms from being submitted more than once. This module also
provides the Permission class, which stores sets of specific tokens
signifying permissions that are granted.
QP does not provide ssl service, but your QP applications can have https support by using
To use the stunnel method, just install stunnel (available from www.stunnel.org) and configure it to run in server mode and to accept connections on the public ('https_address') interface and forward them to the port on the local ('as_https_address') interface. The host and port of both of these interfaces must be identified in the SitePublisher's configuration dictionary.
The standard installation uses Apache, but the lighttpd HTTP server can be used similarly since it supports SCGI and SSL.
The following are the minimum lighttpd.conf customizations required to enable SCGI and set up a virtual host for http and https::
server.modules = ("mod_access",
"mod_scgi",
"mod_accesslog")
$HTTP["host"] == "www.example.com" {
$SERVER["socket"] == "0:443" {
ssl.engine = "enable"
ssl.pemfile = "/www/ssl/server.pem"
ssl.ca-file = "/www/ssl/server.crt"
}
scgi.server = ( "" =>
( "localhost" =>
( "host" => "127.0.0.1",
"port" => 7003,
"check-local" => "disable",
# default disable-time is 60 seconds
"disable-time" => 5 # seconds
)
)
)
}
The QP package incorporates the work of the MEMS Exchange software
developers going back to approximately late 2000. Other
contributors include:
Michael Watkins
David Hess
Maas-Maarten Zeeman
Peter Wilkinson
Mario Ruggier