On Oct 30, 2006, at 9:47 PM, Sells, Fred wrote:

> If I have read the docs correctly, the differences are
>
> 1. QP requires python 2.4 while Quixote works with 2.3

Not out of the box... minor changes (that may actually not be needed if
not using some specific features) outlined in:
http://mail.mems-exchange.org/durusmail/quixote-users/5602/

> 2. QP uses Durus for persistent store, while Quixote (with session2)
> can use
> MySQLDb and others

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.

> 3. both can use scgi
> 4. both can use PTL although QP requires Qpy, while Quixote has it
> included.

I guess that Qpy is not included in QP because
(a) it is of standalone interest
(b) you do not have to use it if you do not want to -- you can use any
templating you wish.
The huge difference here I would say is that Qpy has proper unicode
support... this alone is enough reason to use QP for me! Installation
of Qpy as separate package is rather trivial.

> 5. both have the same url to module/class/method mapping
>
> I am leaning toward Quixote, rather than QP because our servers are
> running
> python2.3 and my management takes a dim view of installing an alternate
> python and of modifying any package to work with python2.3 (i.e. QP).
> Some
> of my assumptions/constraints are...
>
> a.  I cannot use any of the Apache authentication features, because I
> am
> tied to a legacy system and must use that for authentication.
>
> b.  Authorization is via ldap (already have python ldap working) and
> uses
> groups to determine access.  The pattern is not consistent enough to
> use a
> generic mod_python handler.  Each application must be responsible for
> it's
> own.

You would need to supply the required methods for authentication, as
per the class qp.pub.publisher.DurusPublisher. If these will be
different per site, you need a Publisher subclass per site. You may
need to supply a  Publisher.ensure_signed_in_using_ldap() method.... In
any case, these custom auth methods you will still need to supply
whichever framework you use.

> c.  Although I do need session management, I do not need it to survive
> a
> server restart; so I assume the built-in session management in Quixote
> will
> suffice. No need for either Durus or Session2.

If user objects are external, you could (a) you can still use Durus
with a modified Session class (that does not assume that Users are also
Durus Persistent objects) or (b) just store the sessions in some other
way... e.g. in memory if longterm persistency is not an issue.

> d.  Although our first two applications which will be deployed this
> way are
> Ajax (using dojo). That may not always be true and I can control
> access to
> both ajax/json data and to web pages in this manner.

I do not see how this would be different in the two frameworks.

> BIG QUESTIONS ---
>
> 1. Am I missing something and making a mistake?
>
> 2. we've always used Apache 2.0, but as I look at what we're doing, I
> wonder
> if we even need it or should just go to simple_server.py or
> scgi_server.py,
> etc.  All our legacy web pages are remaining on the legacy system,
> this is
> all new work with a RedHat system as a dedicated web-server.  We don't
> use
> Apache's virtual servers.
>
> I'm still a light-weight in this arena, having come from a rich client
> java
> world.  Any advice would be appreciated.