On Mar 7, 2006, at 5:58 PM, Mike Orr wrote:

> Neil has specific ideas about what QP should be, and it's tightly
> integrated with Durus, Dulcinea, QPY, and the MEMS Exchange's other
> applications.  These base technologies are a radical departure from
> the Python web mainstream, and thus unacceptable to a large percentage
> of programmers.  If you've done a bit of work with SQLObject, MySQL,
> and Cheetah before -- enough to trust them -- you are unlikely to
> accept a different system like Durus that would have to be thoroughly
> tested and doesn't have that many users.

Durus itself is pretty well tested.  Still, you are correct that
a big change in the backend of an app is a risk that people would
naturally want to avoid.

> Of course, one can use an
> alternate template or database system with QP, but this would have to
> be shown in the manual.  I don't think the use of QPY and Durus
> internally is a showstopper; users can consider them an
> "implementation detail".  Since Durus is small, it can be considered
> an acceptable baseline for persistent sessions.  (Dictionary sessions,
> Quixote's default, are incompatible with multiprocess deployments like
> SCGI.)
>
> I had assumed that QP expected you to use Durus for your application
> data as well as for the internal session stuff, but when I mentioned
> this to David he said, "Well, I don't see any reason you can't do
> that."  Meaning he'd just as likely expect an application to use some
> other database for its application data.  Of course, this other
> database can be anything.

I don't know of obstacles to using some other database, but QP
does, out of the box, expect Durus to be used for users and sessions.
If there are some obstacles to using another database in QP, I'm pretty
confident that they could be resolved without too much trouble, though
some of QP's features would not be available.

>
> Another thing about QP is the convention of URL callables (please, can
> we call them "controller methods" instead?) calling header and footer
> functions to build the entire HTML page.  This adds some clutter.  In
> Cheetah or Kid you'd use template inheritance to take care of this, or
> in my case I made ._q_traverse do it.  But of course, this is just a
> convention in QP.  It's just something to mention in the manual, that
> you don't have to do it that way.

Another pattern used in some places in QP (and Dulcinea) is a
page() function that wraps your content with your standard header
and footer.

>
> The main thing in QP I see as a potential problem is that you have to
> make a symlink from the QP installation to your site directories.
> This implies you can have only one set of QP sites on a system, and
> users can't have their own in their home directories.  Is this symlink
> really necessary, or can the sites directory be specified another way,
> such as relative to the startup script or configuration file?

In qp, the qp.sites package *is*, in effect, the configuration.  There
isn't any site-specific startup script or other configuration file.
If you wanted to support sites from different places in the file system,
you could put symlinks to the individual site directories inside the
directory of the qp.sites package.  To support this multiple-programmer
model, I think the "qp" script would need to be modified to narrow the
list of sites to those whose directories are owned by the user running
the "qp" script.