Some QP users may not want to use Durus, and I would like to make
QP useful for them, too.  One approach is to separate and adapt
the APIs for the Publisher and the Session and User classes as
Mario suggests.  I think, however, that the audience that is reluctant
to use Durus is probably also reluctant to write the adapter that
makes their stored users and sessions work just like the ones in QP.
And if they don't, for whatever reason, work just like the ones in QP,
the consequences could be ugly.

Here is an alternative approach.  Every QP site defines a site-specific
Publisher class.  For sites that do not wish to use Durus, this class
should override the process_hit() method.
(A Hit holds a request and a response.)
This gives your application total control over the response
to each request.  Your implementation can use *any* method it wants
to set up the response.  Any database, any template system, any
logging, any error handling.

This approach does lose much of the out-of-the-box functionality
that QP provides for Durus-based applications, but I think it still
might be attractive because you get
     to use your existing database and database skills,
     your favorite traversal/page construction method(s),
     request/response classes that are fairly mature,
     multi-site management pattern, and
     a built-in multi-process http/scgi server.


---

I think both of these approaches need a little change in the QP code
to allow for sites without any Durus database, and I'll go ahead with
that.