On 11 Sep 2007 12:51:35 +0100, hollowsun@waitrose.com wrote:

> In a previous mail Mario wrote (about sessions): "You are not
> obliged to use Durus. Any other persistence mechanism will do, as
> long as you satisfy the API as defined in the class
> qp.pub.publisher.DurusPublisher." I was wondering if anyone had
> already done the work and plugged QP into MySQL or even better
> PostgresSQL? I have nothing against Durus, in fact like it, but my
> hosting provider already provides MySQL and Postgres instances for me
> to use and will charge extra for using Durus because it will count as
> another chargeable "long running process" along with QP itself. An
> increase in cost I'd like to avoid. Regards, Tristan

I had not done it. Had the intention to remap the user and session modules
to an sqlalchemy model, and derive an adjusted DurusPublisher class to
communicate with it instead. But for me it was mostly an exploration, that
got bypassed. It would be an interesting development though, as it would
open up the use of qp for a whole lot of other contexts. Note that there is
an additional consideration -- the qp control script that currently assumes
the db is durus.

Recently, on the Durus mailing list, Mike announced experimental sqlite and
postres storages for durus
[http://mail.mems-exchange.org/durusmail/durus-users/887/]. Iiuc, as they
are these would anyway not help to meet your requirement (of not having
another server process), but I wonder if, with some tinkering, there'd be
any possibilities there.

mario