On Mar 7, 2006, at 12:29 AM, Mike Orr wrote:

> TG has implemented
> pluggable templates (TurboCheetah, TurboStan, etc), and is
> experimenting with replacing CherryPy with a minimal traversal library
> (RhubarbTart) linked to Paste, and with replacing SQLObject with
> SQLAlchemy.  My own project is having problems with SQLite
> performance, and I may have to substitute Durus or put the 30 MB
> database into memory.

Do you mean you consider switching to Durus from SQLite due to a
performance issue with this particular project?  SQLite is already a
lean and mean db, and with such a small amount of data I would
certainly be very curious what specific issues you are having that
would make you consider such a switch... (and that could be a big
separate discussion, so may be over on the durus list?).

W.r.t your comments on the framework's "db component", working with QP
I realize that the interface  between QP and the special data classes
it expects (i.e. user and session) is really quite minimal, and I'd say
very feasibly replaceable by your ORM of choice, or any other OO layer
of course. (There is of course a lot of interaction within the classes
themselves, but with QP "on the outside" of them there is surprisingly
little). I mention this because I think this openness is a point in
QP's favour (I'd hazard a guess that replacing the ORM in django or TG
will be a whole other story), and because it makes me think that the
conceptual difference between Quixote and QP is as big as one (me;)
might expect. Of course QP has numerous improvements, such as QPY, but
Quixote would anyway have to improve in the same ways...

So, you talk about Quixote 3 -- I think that would be another name for
QP made slightly more open, in particular giving QP the option to run
without a db, and formalizing the interaction it would require from the
db when it is used with one. I think that would be an interesting route
down which to merge the 2 frameworks.

mario